Refactor Feast Helm charts for better end user install experience

What this PR does / why we need it:

Use --spring.config.additional-location to specify Spring application config
so the default application.yaml bundled in the jar can be used, and users
only need to override required config. This is to prevent chart users being
overwhelmed by the amount of config to set.

Use less templating, if else, and functions in configmap.yaml in Feast
charts. Instead set a reasonable default and allow users to override
in application-override.yaml. This makes it easier to manage when
application.yaml structure changes and documentation for application.yaml
can be delegated to:
https://github.com/gojek/feast/blob/master/core/src/main/resources/application.yml
https://github.com/gojek/feast/blob/master/serving/src/main/resources/application.yml

Remove double nesting of charts. Previously, Postgresql and Kafka subcharts
are bundled in Feast Core suchart. Now all 3 subcharts are sibling charts.
This reduces coupling between charts and it's easier to configure chart
values one at a time than one big values yaml. Also, documentation for
third party subcharts can be delegated to the original authors.

Use helm-docs to generate README for Feast charts so the documentation
is reproducible and easier to keep up to date when values.yaml changes.
It is also easier to follow best practices when writing values.yaml.
https://github.com/norwoodj/helm-docs

Add prometheus and grafana charts to support out of the box metrics
collector and visualization when users install Feast with this chart.

Add tests for users to verify installation:

Add examples to install Feast with 3 different configurations (from simple to complex):

online serving only with direct runner
online and batch serving with DirectRunner
online and batch serving with DataflowRunner

To check how the Chart documentation will look like
https://github.com/davidheryanto/feast/tree/helm-chart-v0.4-refactor/infra/charts/feast

Which issue(s) this PR fixes:

NONE
Does this PR introduce a user-facing change?:

Yes, the format of Helm values passed during installation has changed, from nested to flatter structure. But in general, the accepted values in each chart are the same.

/retest

/retest

Some of this is really great, the different configuration locations and documentation around it is a mess.
However, this PR introduces a lot of breaking changes without workarounds.

Use --spring.config.additional-location to specify Spring application config
so the default application.yaml bundled in the jar can be used, and users
only need to override required config.

Additional spring configs are already supported through profiles which can be toggled on and off. This PR forces all the additional files with hard-coded contents are used.
If you want to use the default, you should use something like this instead of spring.config.additional-location:
-        - "--spring.config.location=file:{{ .Values.springConfigMountPath }}/"
+        - "--spring.config.location=classpath:/application.yaml,file:{{ .Values.springConfigMountPath }}/"

This will continue to allow profiles and the files to be used. For example, an additional use-case is to provide a custom profile with complete database settings that point to a managed service.

Use less templating, if else, and functions in configmap.yaml in Feast
charts. Instead set a reasonable default and allow users to override
in application-override.yaml.

Setting defaults for non-deployed services is undesirable and leaves confusion over what needs to be overridden and what will take precedence.

Remove double nesting of charts. Previously, Postgresql and Kafka subcharts
are bundled in Feast Core suchart. Now all 3 subcharts are sibling charts.

I believe part of the reason for this is to check wither the dependencies are enabled and get access to their configuration. Using siblings makes assumptions about configuration and does not allow you to check which are enabled.
Other observations:
SPRING_DATASOURCE_PASSWORD is enforced and requires a pre-existing secret. Imagine you want to encrypt your DB password in the values file (e.g. in a profile), this is no longer possible.
jvmOptions moved to javaOpts, removed from command and defined as environmental JAVA_OPTS. The java start command does not make use of the environmental variable and hence options will be ignored.
Server port is hardcoded.
jarPath is no longer supported.
Overall, I think this PR makes an assumption that the Feast chart will deploy all dependant services and tightens the coupling. This is very unlikely to be the case for [shared or managed] services like Kafka and Postgres.

Hi @Yanson thanks for the feedback.
My main motivation for updating the Helm chart is to simplify the installation steps (may be at the expense of less configurability, and a few breaking changes) so it is easier for users to get started. And to consolidate the documentation so there is mostly one source of truth (for example rather than documenting application.yaml in the Helm chart, I refer to the application.yaml in Feast Core resources folder, where it is better documented and is always up-to-date)

This PR forces all the additional files with hard-coded contents are used.

Maybe I'm missing something but I don't see how this PR forces the additional files with hard-coded contents. This PR provides user with one and only way to override config, via application-override.yaml. I'm following the approach used by Kafka chart https://github.com/helm/charts/blob/master/incubator/kafka/values.yaml#L173
However, some of the defaults are modified so it suits Helm installation better. For instance the default spring.datasource.url in  https://github.com/gojek/feast/blob/master/core/src/main/resources/application.yml is pointing to Postgresql in localhost:5432. The default is modified to release-name-postgresql:5432/postgres. This is to support first time users who just want to try install Feast with helm install --name myrelease feast.
So this chart modifies the default configuration (which is usually not valid anyway for Feast installation in Kube cluster), so it supports the most minimal installation option. Users can and are advised to override this default via application-override.yaml if they need to.
I understand that this Helm chart now disables the use of providing configuration via Spring profiles. But again my reasoning is to simplify configuration so users only use one application-override.yaml to specify options.
With profiles support, users need to somewhat process how these profiles are eventually gonna end up in the final config. And whether the configuration provided via profiles or those provided via application.yaml are going to be used. This requires users to also have a bit of understanding how Spring profiles work.
Is using (perhaps multiple) profiles compared to a single application yaml is a better practice and preferred approach? If yes, we should add again the profiles support.

Setting defaults for non-deployed services is undesirable and leaves confusion over what needs to be overridden and what will take precedence.

I think this depend on the application. For Feast Core e.g dependencies on Kafka and Postgresql service is required. The default is to faciliate easier installation if user is to install these dependencies using default config. If not, they can set their own setting via application-override.yaml. I think the naming of this field makes it obvious that it takes precedence.

I believe part of the reason for using nested charts is to check whether the dependencies are enabled and get access to their configuration. Using siblings makes assumptions about configuration and does not allow you to check which are enabled.

Yes at first, this is what we thought. But after some experiences with using this approach, I feel the subscharts approach, without nesting feels more flexible. For instance, sometimes we want to migrate, backup or update the dependent services e.g. Kafka, Postgres or Redis deployments. With them being a child subcharts of Feast Core and Serving, migrating may involve changes to the parent Feast Core and Serving parent, and may accidentally update Feast Core and Serving (which we do not want esp if they are serving production traffic). With these dependent services being separate subcharts, updates to these are more independent. This seems to be the approach taken by istio too https://github.com/istio/istio/tree/release-1.5/install/kubernetes/helm/istio. Also making these dependent services sibling vs child subcharts, allow us to more easily upgrade their Chart version. With nested approach there may be some dependencies created between the parent and child.

SPRING_DATASOURCE_PASSWORD is enforced and requires a pre-existing secret. Imagine you want to encrypt your DB password in the values file (e.g. in a profile), this is no longer possible.

This is to encourage best practice to prevent the setting of plaintext password in the application.yaml, by enforcing the use of secret for saving passwords. If users encrypt the DB in values file, in profile, I'm sure there are other configs that they will need to provide as well to decrypt this password etc. I'm not sure what common approaches there are but we can always extend this although I think it will make configuration more complex.

jvmOptions moved to javaOpts, removed from command and defined as environmental JAVA_OPTS. The java start command does not make use of the environmental variable and hence options will be ignored.

JAVA_OPTS is a commonly used environment variable used by JVM unless maybe they have changed it?
https://github.com/helm/charts/blob/master/stable/metabase/templates/deployment.yaml#L102
https://github.com/helm/charts/blob/master/stable/jenkins/templates/jenkins-master-deployment.yaml#L182
I changed the name from jvmOptions to javaOpts to make it more consistent with other Helm charts in stable repository.
It is specified in env variable versus command to make the command simpler.

jarPath is no longer supported.

I think this use case is quite unusual. Unless users build custom Feast images, but if they do, they can always build it such that the feast jar is at the correct location. I checked other charts in stable repo. Most does not provide this option too:
https://github.com/helm/charts/blob/master/stable/jenkins/templates/jenkins-master-deployment.yaml#L101
https://github.com/helm/charts/blob/master/stable/spinnaker/templates/statefulsets/halyard.yaml#L35
I feel removing options that are rarely useful and used ease the burden of people configuring the installation.

Overall, I think this PR makes an assumption that the Feast chart will deploy all dependant services and tightens the coupling. This is very unlikely to be the case for [shared or managed] services like Kafka and Postgres.

The assumption is true only if users install this chart with the default enabled options. Users can completely disable Postgres,Redis and Kafka installation in this chart. And assuming they have these installed externally, they can set the config to connect to these external services in application-override.yaml
I'm open to recommendation and fixes. But current PR is biased towards favouring simplicity (in the sense of one single source of truth) over configurability (various ways to provide config in multiple places). But maybe the latter is the preferred one?

@Yanson I am reviewing this PR now. I want to make sure we address any concerns you have. I much prefer the simplicity that this PR brings, especially because I am working on a refactor as part of #525. It can be hard for us to keep up with maintaining documentation and configuration, as you might have noticed. We're trying to reduce the surface area of configuration as much as possible to decrease the burden on our engineers, while at the same time hopefully providing escape hatches for you to customize it.
I still have a few open comments on the discussion
Spring Profiles:
I am not 100% sure if it is necessary to support additional Spring profiles. Is there anything that can be done with additional profiles that can't be done with the application-override.yml?
In the ideal case a user of Feast shouldn't know that Spring is being used at the back. Having this exposed at the Helm level seems unnecessary to me, at least at the level of values.yaml
We also have a PR (#493) from @pmjacinto that adds Kube secrets that map to spring profiles. @davidheryanto, how would you propose we handle those?
Coupling:
You mentioned that we are increasing coupling with this PR. It seems like we are moving to more modularized component dependencies. Can you explain what you meant by that?
Setting default for services:
I think it makes sense for a values.yaml to contain defaults since this makes installation simpler and it is a known user facing API. They know they have to modify it. My concern would be more in terms of any default configuration set inside the chart itself. I agree with both of you here. For Kafka and Postgres it makes sense to have defaults in place, but we don't want to have magical defaults that are hard for users to see and configure, especially if there is a high likelihood that they would want to change it.
The implementation here for the Feast Core Configmap contains 3 profiles. It's not clear why we need three profiles there. Also I agree that the configuration would ideally not be hardcoded inside the chart. Especially not ports
It seems like the biggest drawback with @davidheryanto's approach is that if the user is tasked with dumping all of their configuration in an override yaml, then they don't benefit from any config generation. A good example is here
bootstrapServers: {{ printf "%s:9092" (printf "%s-kafka" .Release.Name)
That being said, it also leaves the chart a lot more flexible. We aren't constrained by the existing conditionals.
It would be highly appreciated if you could enumerate any pains that remain, given @davidheryanto's response.

There is a lot going on in this MR which makes it difficult to discuss the changes as there are multiple threads. I know it's taken me a week to reply but it is high on my agenda so please can we all be on the same page before moving forward.
Profiles

I don't see how this PR forces the additional files with hard-coded contents

What I am referring to is the list of files specified in spring.config.additional-location; default-postgresql, default-kafka, default-statsd. These files are a. created, and b. specified as configuration, regardless of whether those services are deployed or not.
The profiles approach is incredibly similar to this, only that it lets the non-required files be omitted from the specified configuration. I found it a tidy way to separate concerns without exposing Spring fundamentals it to the user. The additional option to define and use arbitrary profiles is overkill for what I wanted to accomplish.
If the same goal can be accomplished (which it can) with application-override.yml and application-secret.yml, I am all for that 👍
Defaults
One major point of concern here, is there are multiple default values making it difficult to understand what the default is, which needs to be specified and which need to be overrided. 1/ resources/application.yml, 2/ templates/configmap.yaml  (some of which are calculated), 3 values.yaml, 4 environment / pre-existing secret.
For example, feast.stream.options.topic is feast-features in resources/application.yml but feast in configmap.yaml. If we are saying that resources/application.yml should be where the defaults live, I might think "I am happy with the topic but I need to change the broker to kafka.mycompany.com". So I go to values.yaml, find the application-override.yml and specify the setting (bootstrapServers). Unbeknownst to me, the topic has been modified by application-default-kafka.yaml, the definition of which is in templates/configmap.yaml and on top of this, it's for a service I didn't deploy.
Pre-existing secrets
Dependency on pre-existing secrets removes some simplicity from the goal of just being able to deploy the chart with defaults. It forces the user into a deployment strategy they might not want (not deploying everything as code).
Specifically on SPRING_DATASOURCE_PASSWORD - this is an override on top of all the other places we might define the value. resources/application.yml defaults to password but falls back to DB_PASSWORD env. Specifying it myself in application-override.yml (or application-secret.yml if we make that) doesn't work. I NEED to make the secret with a given key (postgresql-password) defined in deployment.yaml.
Minor points

jarPath is no longer supported.

We create our own image with different conventions which is why I added support for that. You're right we can put it at the "correct" location, according to Feast. So probably not worth the overhead of supporting configuration for this.

I changed the name from jvmOptions to javaOpts to make it more consistent

I don't mind what it's called as long as the upgrade guide explains that it changed.

JAVA_OPTS is a commonly used environment variable

This variable needs to be read by something and passed to the java command. In the charts you link, they have an entrypoint script which does that. In this chart, there is no script - the raw command is specified in deployment.yaml.
Sorry I don't have time to go into any further depth on any point today, but hopefully I've covered most of the points.

it is high on my agenda so please can we all be on the same page before moving forward.
Thanks for taking the time to respond @Yanson. I'm happy to take some time to get this right. As you have rightly pointed out, there are many things going on in this PR which makes it a little bit harder to review in one go.

Let me review all of the comments again and see if I can come up with a list of changes we agree to and ones that are outstanding.

Thanks for your patience here @Yanson and @davidheryanto.
Before we continue, do note that the application.yml have changed for both Core and Serving. This PR is related to #525 in that sense. We can create an upgrade guide once we cut a release. Going from 0.4 and 0.5 will have quite a few breaking changes.
Anyway, to get to the task at hand.
Design goals

Make it easy for users to get started
Make it easy for Feast contributors to maintain these charts and configuration
Provide escape hatches to power users

Recommendations

Let’s move configuration defaults to as few places as possible.

Use the existing application.yml that comes with Core/Serving (resources/application.yml) for the minimal sane defaults. It's also the place that we keep documentation (along with Protos) and refer users to.
For Helm: I’d recommend moving all the existing default configurations (from Config Maps or other places) into application-override.yml key, and document the fact that this overrides or merges with resources/applicaton.yml.
The combination of the above should allow an easy installation for new users, and a means for power users to modify all configuration
(Optional) Add a flag to disable all configuration in resources/application.yml

Add support for application-secrets.yml. Works just like the application-override.yml, but it's stored as a secret. It would be the 3rd and final .yml added to the jar path. We can add this as part of #493.
We can set _JAVA_OPTIONS instead (example)?
Add envOverrides like Kafka (example). This would provide users with one more layer of an escape hatch if they want to set spring config
Make existingSecret conditional. Ignore it if it isnt set.

Open questions

Is the expectation that the user would set application-override.yml by hand? Meaning we can’t interpolate Helm vars like {{ .Release.Name }}-redis-master any more. I guess this is reasonable for now.

Yeah the recommendation looks good as it provides reasonable default configuration for many users (so new users will not need to read through all the available knobs and options to get started) and still provides advanced users ability to override all these default options.
I like the Kafka envOverrides too as it provides an alternative for users who prefer to specify options via env variable vs configuration yaml file.

@woop this looks like a good way to move forward.
I didn't know about _JAVA_OPTIONS but having dug a little into it, it seems JAVA_TOOL_OPTIONS is more suited:
https://bugs.openjdk.java.net/browse/JDK-4971166
I think the cleanest thing to do is hard code everything in application-override.yml, i.e. that is a property of values.yaml and there is no interpolation of release name (etc). Given this is only for getting started quickly, we can assume the release name, port selection etc.

this looks like a good way to move forward.

I think the cleanest thing to do is hard code everything in application-override.yml, i.e. that is a property of values.yaml and there is no interpolation of release name (etc). Given this is only for getting started quickly, we can assume the release name, port selection etc.

Great. I think its a safe first start that doesn't prevent us from adding more flexible options in the future.

I didn't know about _JAVA_OPTIONS but having dug a little into it, it seems JAVA_TOOL_OPTIONS is more suited: https://bugs.openjdk.java.net/browse/JDK-4971166

Good catch. Let's use JAVA_TOOL_OPTIONS

The chart has been updated so it will work with the current application.yaml format in master (to be v0.5)
Also these modifications that we discuss:

Allow users to set application-secret.yaml in Helm values for Feast Core and Serving. This works similar to application-override.yaml but will be created as a Secret and has a lower precedence than  application-override.yaml
javaOpts Helm values will become the environment variable value for JAVA_TOOL_OPTIONS
Add envOverrides to support arbitrary setting of env variables e.g. when application-override.yaml is not sufficient
feast-core.existingSecret is now optional. However it is recommended to use this approach so it will work seamlessly with the Postgresql chart.

Thanks, I will see if I can try out this version today or tomorrow to validate it.

Thanks @davidheryanto, the changes look good. I especially like the level of detail in the README.md
One thing that stands out though. Previously we wanted to do this:

For Helm: I’d recommend moving all the existing default configurations (from Config Maps or other places) into application-override.yml key, and document the fact that this overrides or merges with resources/application.yml.

This suggestion was so that we didn't have hardcoded application.yml files in the configmaps as well as at the jar path

So basically we just need something like (no kafka, postgres, statsd)
- --spring.config.additional-location=/etc/secrets/feast/application-secret.yaml,/etc/feast/application-override.yaml

Otherwise the chart is too hardcoded as @Yanson said. I mean it feels like we are stuck between two worlds. Either we define everything in values.yaml and we have to do more work in hardcoding it, or we generate the configuration with templates from variables. But this current approach doesnt do either well.

Hi @davidheryanto, thank you for the changes. It's looking very clean now.
Just a few minor things to note:
Feast Core
Only items apply to both, see further down.
Feast Serving
feast-serving/templates/_helpers.tpl

bq_store_and_no_job_options no longer used

Both
templates/deployment.yaml
prometheus.io/port: "8080"
Other places in the file use {{ .Values.service.http.targetPort }}
Note, the above value needs to match the Spring Boot setting (which is currently defaulting to 8080). We should document how to change the Spring setting and that they need to be aligned.
The same goes for service.grpc.targetPort
GOOGLE_CLOUD_PROJECT=.Values.gcpProjectId
Missing documentation in values.yaml.
template.metadata.annotations
Checksum annotations are missing to force redeploy on config changes.
src/main/resources/application.yml

It might be worth removing the env placeholders with fallbacks as that is another point of confusion. e.g. username: ${DB_USERNAME:postgres}. These can be overiddedn with env anyway.
Perhaps rename to .yaml to match all the other config names.

Third party
Discussed with @woop it would be cleaner to remove the third party charts and document running helm dependency udpate, OR just include the tgz.
Not sure if prometheus-statsd-exporter is packaged anywhere, if not you can use our vanilla-service with these settings (which is what we do):
helm repo add konnekt-public "https://konnekt-public-charts.storage.googleapis.com"

helm install statsd-exporter konnekt-public/vanilla-service --version 0.19.0 -f values.yaml

Where values.yaml is:
image:
  repository: prom/statsd-exporter
  tag: v0.12.2

resources:
  limits:
    cpu: 250m
    memory: 256Mi
  requests:
    cpu: 25m
    memory: 64Mi

container:
  args:
  - --log.format=logger:stdout?json=true
  port: 9125
  portName: statsd
  portProtocol: UDP
  readinessProbeAction: tcpSocket
  livenessProbeAction: tcpSocket

# Enable for a GCP internal load balancer
# ilb:
#  enabled: true

service:
  port: 9125

ingress:
  enabled: false

prometheus:
  enabled: true
  path: /metrics
  port: 9102

Thanks @Yanson for the feedback.

Removed bq_store_and_no_job_options from feast-serving/templates/_helpers.tpl

Set prometheus.io/port to {{ .Values.service.http.targetPort }}.

Regarding documentation on how to change this from the Spring config, I think we should leave it to another issue or PR: to document the application.yml on how to change the HTTP port. Similarly, regarding this part username: ${DB_USERNAME:postgres} and yml vs yaml extensions. So that this PR will not have unattended side effects and
is mainly about deployment of Feast with Helm charts using the
existing Spring config.

For .Values.gcpProjectId actually I was thinking if this value is necessary? Since in order to configure the Dataflow runner, we already require the person configuring Feast deployment to specify the project ID. Similarly, for BigQuery as the Serving store and Deadletter store.
Given this, it may generate confusion to users regarding which project is actually being used, if we also provide this option .Values.gcpProjectId

Added the checksums in the deployment template spec so changes in the
configmap and secret will trigger rolling updates of Feast Core and Serving.

For 3rd party charts, I actually follow the approach taken by istio https://github.com/istio/istio/tree/1.5.0/install/kubernetes/helm/istio to include the chart source files directly as opposed to include the packaged .tgz file. Mainly because we may want to include additional files and modify slightly the defaults in these 3rd party charts:

If Feast is to pre-include Feast specific Grafana dashboard JSON (such as charts showing ingestion lags and feature statistics) and automatically configure it with the prometheus datasource if installed together in this chart, I feel it makes sense to have the 3rd party Chart in the source files format. So that these extra dashboard JSON and datasource configuration can be more easily configured.
Some of the defaults in the 3rd party charts can be modifed so it fits Feast defaults better. E.g. the prometheus charts by default will install the push gateway which currently Feast does not use at all. We can disable this default from top-level values.yaml or setting it in the values.yaml in the prometheus chart. The latter allows the top level values.yaml (which is closer to the end-user) to be cleaner because it will only consists of enable: true/false toggle.

Of course the drawback is upgrading these 3rd party charts will require more effort than just simply increasing the version number in requirements.yaml. But I don't foresee we need to be doing such upgrades frequently.

Thanks for addressing.

Happy for docs to be handled in a separate PR.

gcpProjectId this is definitely needed by us. It shouldn't be and took a while to debug, but I found one of the google SDKs was not correctly selecting the project from the JSON key and using the metadata server (project it's running in). Hence why I added it. It might be difficult to explain where/when it's used.

Will need a bit of time to verify the new changes.

I don't agree about the 3rd party charts. It makes it very difficult to understand what is Feast code and what is imported. Regarding changing or adding files, this makes things even worse, as you say for upgrading and comparing what we might have to re-implement with their new version. We should "modify" (customise) through the values options they expose. It's not a show-stopper for me, I just think it inflates the codebase unnecessarily. We'll be disabling them all and deploying separately anyway 😄. I'll let you and @woop decide what to do.

@davidheryanto Thanks for being so responsive here.
On the topic of expanded charts. I don't find the current points super convincing.

Grafana dashboards: I am not sure I follow how having an expanded chart here helps. Can we get away with not including that for now?
Defaults: If its only for defaults, then I dont see a big need to do this.
It seems to go against the idea of reduced management for the Feast team if we are expanding the charts.

one of the google SDKs was not correctly selecting the project from the JSON key
@Yanson It's funny because I am also running into this problem now.

Could this be the issue?
https://github.com/gojek/feast/blob/v0.4-branch/ingestion/src/main/java/feast/ingestion/utils/StoreUtil.java#L115
Solution: https://stackoverflow.com/questions/45246449/passing-service-account-credentialjson-file-programmatically-for-bigquery-serv

Ok I removed the 3rd party charts from the charts folder.
I'm ok either way with the gcpProjectId configuration.

Thanks @davidheryanto.

Ok I removed the 3rd party charts from the charts folder.
I'm ok either way with the gcpProjectId configuration.

Think the following is still pending:

I think we need to add gcpProjectId into the documentation. That is just code gen right?
Out of date configuration for stores in the examples.

Almost done!

@woop Oh yes, I forgot to update the values-*.yaml example files. It's now updated to Feast v0.5 config structure. I also added Helm values doc for .Values.gcpProjectId

@woop Oh yes, I forgot to update the values-*.yaml example files. It's now updated to Feast v0.5 config structure. I also added Helm values doc for .Values.gcpProjectId

Thank you @davidheryanto. Really appreciate the effort on this one. I am happy to merge.
@Yanson We've probably missed some small details here and there since the surface area of these charts is pretty massive. I think we should get this in and create a new issue if we need any more changes.

/lgtm


Support for incremental builds

Hello MBT Team,
in the Roadmap the support for incremental builds was mentioned to be available in Q3-4/2019. As it's now already Q4/2020 I would like to know if the feature was already delivered but the roadmap needs an update?
Best regards
Gregor

Hi Gregor,
Yes, we delivered the feature: "Supports incremental builds; in other words, one module at a time.".
You can now use "mbt module-build" command to build modules individually. Here https://sap.github.io/cloud-mta-build-tool/usage/#auxiliary-commands you can find more details on the command options.
Regards
Natalia

Thank you @katunin-ng  for the quick response. So it would be great if the Roadmap page can be updated.

Hi Gregor,
You are right. I will take care.
Regards
Natalia


[release/1.0] Return a better error message is unix socket path is too long.

Signed-off-by: Kenfe-Mickael Laventure<EMAIL_ADDRESS>(cherry picked from commit 3c3a676490970dd759b940c9982130aa2f71da87)
Signed-off-by: Stephen J Day<EMAIL_ADDRESS>

Codecov Report

Merging #2256 into release/1.0 will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release/1.0    #2256   +/-   ##
============================================
  Coverage        50.78%   50.78%
============================================
  Files               81       81
  Lines             7176     7176
============================================
  Hits              3644     3644
  Misses            2832     2832
  Partials           700      700

Flag
Coverage Δ

#linux
50.78% <ø> (ø)
: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 51cf56f...34b7c1d. Read the comment docs.

@mlaventure We can probably just merge this one and backport the other PR. ;D


Handle reset similarly to panic.

We don't want control to continue in MicroPython.

Reworked after recent error handling changes.
I'm going to merge this now to avoid more conflicts.


[0.3-mtl] make resize fill configurable

Fixes #2951
PR checklist:

[x] make succeeds (on *nix)
[ ] make reftests succeeds
[x] tested examples with the following backends: metal
[ ] rustfmt run on changed code

Also sets up the properties of a swapchain to be inherited.

bors r+


Small error in docs

Hi, just letting you know I noticed a small error in the documentation.
At the bottom of this page https://dmey.github.io/synthia/examples/fpca.html
The error is in line [6] of the code, under "Plot the results".
You have:
plot_profiles(ds_true, 'temperature_fl')
But I believe it should be:
plot_profiles(ds_synth, 'temperature_fl')
you want to plot results, not the original here.
Cheers & thanks for the cool project!

Good catch! Fixed in #29. Thanks!


Support "not in"

The following code is not supported:
if value not in items:

end

This has to be written as:
if not (value in items):

end

If implemented as syntactic sugar this would probably be very easy.

If implemented as syntactic sugar this would probably be very easy.

The main idea is that when the syntax is very much like python it does that consistently


Fix typo on README

Fixed minor typo on the README. You should be able to merge it to the master branch without problems.

Good catch. Thanks!


dataset file

Is this a dataset file pair? Why is it wrong: it can't find the image file

Hmm did you use the included script to download the dataset or did you download it yourself?
Regardless, you can probably fix this by moving the contents of each test2017, train2017, and val2017 folders into their parent folder (images). That's what the script does.

ok， I have solved this problem. But,when I am running this command"python eval.py --trained_model=weights/yolact_base_54_800000.pth --score_threshold=0.3 --top_k=100 --display", I have a bug：

Thank you for your reply

Oh whoops, it looks like I made a typo. Pull the latest commit and that should be fixed.

oh my friends,Your suggestion is valid.
what's more, if someone meet the issue of  the qt's version , you can upgrade it by"conda upgrade qt".
thanks


ADD recognize weeks

examples:
week nr 23
wk 23
week №23
week # 23
W23
2022#23
first day 9 AM of 2022#23
week number 23
first day 9 AM of 2022 week number 23
2022 week 23 first day 9 AM
2022 week nr 23
2022W23 // ISO format

For the record, ISO format is already supported by PHP DateTime so both Carbon and JenssegersDate inherit it:
new \DateTime('2022W23')
new \Carbon\Carbon('2022W23')
new \Jenssegers\Date\Date('2022W23')

Maybe some other syntax are also natively supported this way.

upstream: https://github.com/briannesbitt/Carbon/issues/2617
but detecting "week" and its formats is a heavily localized thing

upstream said no, so this has to be completed here


Activity Binding

I don't find this class com.saulmm.cui.databinding.ActivityHomeBinding. I'd like to see because it will be very interesting!

Hello!
ActivityHomeBinding is an autogenerated class by the Databinding library, That activity refers to the activity_home.xml file, and it's under the build folder. That's the reason that you don't find it :)

Hi @saulmm, thanks, I did't know this library. Wow, it's very good! Thank you!

👍


Google Sign In iOS issue with iOS 9.2

With Xcode and iOS 9.2, when i run the Google Sign In sample, the google sign in controller gets pushed instead of presented.
I have the same behaviour when running the sdk in my code.
When running the same code in iOS 9.1, the sign in controller gets presented, as expected.

Thanks for reporting this, checking if I can reproduce.

@piresbruno do you still have this issue?
@silvolu were you ever able to reproduce?
I am going to close this issue as there has been no activity for 4+ months, but please feel free to re-open if there is more to resolve.


default output filename

currently, the filename is just the song name.
with -o argument, user can make change to it, but i want to ask if you could add options to have few presets like {artist} - {track}.flac.

Hey, I added this feature, you can test if it's working properly.
Use -o with {id} {title} {number} {artist} {album} {artists} variables
I'm planning to add presets to download path too, or just make {artist}/{album}/{title} argument create new directory.

Hey, I added this feature, you can test if it's working properly.
Use -o with {id} {title} {number} {artist} {album} {artists} variables

hi, i just tried and it works fine.


Should have a list of keywords - eg: how to specify  Not Equal, Greater than etc

Should have a list of keywords - eg: how to specify  Not Equal, Greater than etc

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

ID: d322215c-8025-4f21-0700-7dfa7dc5c46e
Version Independent ID: 141fcdbb-8394-525b-bb29-eff9a693a9c4
Content: Stages in Azure Pipelines - Azure Pipelines
Content Source: docs/pipelines/process/stages.md
Product: devops
Technology: devops-cicd-process
GitHub Login: @juliakm
Microsoft Alias: jukullam

You can find more details on our expressions page. I'll add a link to the article.


Changed the signature of createComponentExtension to be aligned with that of React.lazy

Type change: Changed the signature of createComponentExtension to be aligned with that of React.lazy
The declaration:
createComponentExtension<T extends (props: any) => JSX.Element>
breaks with a component that implements the React.FunctionComponent interface with the error:
Type 'ReactElement<any, any> | null' is not assignable to type 'Element'.
Looking at React.lazy, it has the signature:
function lazy<T extends ComponentType<any>>(
        factory: () => Promise<{ default: T }>
): LazyExoticComponent<T>;

This PR changes the signature of createComponentExtension to match that of React.lazy.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)

Tugboat has finished building the preview for this pull request!
Link:

https://pr4843-kfcz7ykfpvhkvhe2vghazvtgo1o27kbi.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/604289d8f285af85aba1a55d

Tugboat has finished building the preview for this pull request!
Link:

https://pr4843-kfcz7ykfpvhkvhe2vghazvtgo1o27kbi.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/604289d8f285af85aba1a55d

Note: the codebase is already using ComponentType elsewhere, as in attachComponentData:
declare function attachComponentData<P>(component: ComponentType<P>, type: string, data: unknown): void;

@bleathem ping - are you ok with the proposed change?

The tugboat Oauth request is a little invasive:

This application will be able to read and write all public and private repository data.

I'm not able to investigate the source of the PR failure.

OK now I think tugboat is chugging along as it should

Tugboat has finished building the preview for this pull request!
Link:

https://pr4843-kfcz7ykfpvhkvhe2vghazvtgo1o27kbi.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/604289d8f285af85aba1a55d


Job queue

This PR reimplements chan chunkWriteJob with custom buffered queue that should use less memory, because it doesn't preallocate entire buffer for maximum queue size at once. Instead it allocates individual "segments" with smaller size.
As elements are added to the queue, they fill individual segments. When elements are removed from the queue (and segments), empty segments can be thrown away. This doesn't change memory usage of the queue when it's full, but should decrease its memory footprint when it's empty (queue will keep max 1 segment in such case).
(Going to test the change in our dev cluster)

@replay Thanks for your review. I've addressed your comments. I've also modified implementation to avoid using len and cap and use two indexes instead (index of next read for pop, and next write for push), I think it makes code easier to read and understand.
I would appreciate if you had a chance to look at the PR again.

Thanks for your review @replay!


Added Diffusion Model Training Project

Also, can we move all the Python directories and files (except the Notebooks) under a src folder?


fix: capitalizing 'or' to 'OR'

Checklist:

[ ] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[ ] I have tested these changes either locally on my machine, or GitPod.

Closes #53311

hi I'm actually confused, chatbot is  directing me to remove the changes to non-english of files
but I updated the english version README file

@SaifullahBijapur

hi I'm actually confused, chatbot is directing me to remove the changes to non-english of files

It looks like everything was resolved so you shouldn't receive any more messages from the bot.
But in general, it is best practice to not work on the main branch when creating PR's.
It always cleaner to work from a new branch.
https://contribute.freecodecamp.org/#/how-to-open-a-pull-request

Hey @SaifullahBijapur
Thank you for opening this pull request.
As there was different PR - #53321 - making all necessary changes, merged recently, we are going to close this one.
Thank you and happy coding! 😊

If you have any questions, feel free to ask questions on the 'Contributors' category on our forum or the contributors chat room.


Respect gene allow list ordering in training data extract

Currently, the extract process doesn't respect the ordering of genes in the allow list table.
dsp-cell-annotation-service.cas_reference_data.refdata-gex-GRCh38-2020-A
It should :D

It was done during june release PR


30 tech terms

Fixes #30.
Fixes #48.
Fixes #42.
See commit message details.

Coverage decreased (-3.08%) to 96.335% when pulling 7e8d8f0450d3fdbbe770a47471a5c5b22dc85b3b on 30-tech-terms into 2f4b840270b8839384d88dd421a4024089c8d995 on master.

Coverage decreased (-0.07%) to 99.346% when pulling 7e8d8f0450d3fdbbe770a47471a5c5b22dc85b3b on 30-tech-terms into 2f4b840270b8839384d88dd421a4024089c8d995 on master.


Path matches but getting [Errno 2] No such file or directory: '/root/usr/local/bin/pg_dump'?

Bug Report
Please help us help you by filling out any applicable information in this template and removing the rest!
Describe the bug
I have django and postgres running in docker containers. I checked the path in the postgres container and used it in base.py DBBACKUP_CONNECTORS but still get the error.
postgres container shell
bash-5.1# find . -name pg_dump
./usr/local/bin/pg_dump

base.py settings
DBBACKUP_STORAGE = 'django.core.files.storage.FileSystemStorage'
DBBACKUP_STORAGE_OPTIONS = {'location': os.path.join(BASE_DIR, '../backups')}
DBBACKUP_CONNECTORS = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        "NAME": os.environ.get("SQL_DATABASE"),
        "USER": os.environ.get("SQL_USER"),
        "PASSWORD": os.environ.get("SQL_PASSWORD"),
        "HOST": os.environ.get("SQL_HOST"),
        "PORT": os.environ.get("SQL_PORT"),
        'DUMP_CMD': os.path.join(
            os.environ["HOME"],
            'usr',
            'local',
            'bin',
            'pg_dump'
            )
        }
    }

Error with DBBACKUP_CONNECTORS settings.
root@af06c150ccb6:/code# python manage.py dbbackup
Backing Up Database: postgres
CommandConnectorError: Error running:  /root/usr/local/bin/pg_dump  --host=postgres --port=5432 --username=postgres --no-password --clean postgres
[Errno 2] No such file or directory: '/root/usr/local/bin/pg_dump'
  File "/usr/local/lib/python3.9/site-packages/dbbackup/utils.py", line 118, in wrapper
    func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 61, in handle
    self._save_new_backup(database)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 74, in _save_new_backup
    outputfile = self.connector.create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 78, in create_dump
    dump = self._create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 38, in _create_dump
    stdout, stderr = self.run_command(cmd, env=self.dump_env)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 21, in run_command
    return super(PgDumpConnector, self).run_command(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 156, in run_command
    raise exceptions.CommandConnectorError(

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 146, in run_command
    process = Popen(cmd, stdin=stdin, stdout=stdout, stderr=stderr, env=full_env)
  File "/usr/local/lib/python3.9/subprocess.py", line 951, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.9/subprocess.py", line 1821, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/root/usr/local/bin/pg_dump'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/code/manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/utils.py", line 118, in wrapper
    func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 61, in handle
    self._save_new_backup(database)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 74, in _save_new_backup
    outputfile = self.connector.create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 78, in create_dump
    dump = self._create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 38, in _create_dump
    stdout, stderr = self.run_command(cmd, env=self.dump_env)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 21, in run_command
    return super(PgDumpConnector, self).run_command(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 156, in run_command
    raise exceptions.CommandConnectorError(
dbbackup.db.exceptions.CommandConnectorError: Error running:  /root/usr/local/bin/pg_dump  --host=postgres --port=5432 --username=postgres --no-password --clean postgres
[Errno 2] No such file or directory: '/root/usr/local/bin/pg_dump'

Error without DBBACKUP_CONNECTORS settings
root@af06c150ccb6:/code# python manage.py dbbackup
Backing Up Database: postgres
CommandConnectorError: Error running:  pg_dump  --host=postgres --port=5432 --username=postgres --no-password --clean postgres
[Errno 2] No such file or directory: 'pg_dump'
  File "/usr/local/lib/python3.9/site-packages/dbbackup/utils.py", line 118, in wrapper
    func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 61, in handle
    self._save_new_backup(database)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 74, in _save_new_backup
    outputfile = self.connector.create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 78, in create_dump
    dump = self._create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 38, in _create_dump
    stdout, stderr = self.run_command(cmd, env=self.dump_env)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 21, in run_command
    return super(PgDumpConnector, self).run_command(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 156, in run_command
    raise exceptions.CommandConnectorError(

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 146, in run_command
    process = Popen(cmd, stdin=stdin, stdout=stdout, stderr=stderr, env=full_env)
  File "/usr/local/lib/python3.9/subprocess.py", line 951, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.9/subprocess.py", line 1821, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'pg_dump'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/code/manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/utils.py", line 118, in wrapper
    func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 61, in handle
    self._save_new_backup(database)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/management/commands/dbbackup.py", line 74, in _save_new_backup
    outputfile = self.connector.create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 78, in create_dump
    dump = self._create_dump()
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 38, in _create_dump
    stdout, stderr = self.run_command(cmd, env=self.dump_env)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/postgresql.py", line 21, in run_command
    return super(PgDumpConnector, self).run_command(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/dbbackup/db/base.py", line 156, in run_command
    raise exceptions.CommandConnectorError(
dbbackup.db.exceptions.CommandConnectorError: Error running:  pg_dump  --host=postgres --port=5432 --username=postgres --no-password --clean postgres
[Errno 2] No such file or directory: 'pg_dump

To Reproduce
Dockerfile
FROM python:3.9.6-slim-buster

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

# Set work directory
WORKDIR /code

# Install system packages required by Wagtail and Django.
RUN apt-get update --yes --quiet && apt-get install --yes --quiet --no-install-recommends \
    build-essential \
    libpq-dev \
    libmariadbclient-dev \
    libjpeg62-turbo-dev \
    zlib1g-dev \
    libwebp-dev \
 && rm -rf /var/lib/apt/lists/*

# Install dependencies
COPY Pipfile Pipfile.lock /code/
RUN pip install pipenv && pipenv install --system --dev

# Copy project
COPY . /code/

docker-compose.yml
version: '3.8'

services:
    web:
        build: .
        command: python3.9 manage.py runserver <IP_ADDRESS>:8000 --settings=IT.settings.dev
        restart: unless-stopped
        volumes:
            - .:/code
        ports:
            - 8000:8000
        env_file:
            - .env/.dev
        depends_on:
            - postgres

    postgres:
        image: postgres:13.4-alpine
        container_name: postgres
        restart: unless-stopped
        ports:
            - 5432:5432
        env_file:
            - .env/.dev_db
        volumes:
            - postgresdata:/var/lib/postgresql/data/

volumes:
    postgresdata:

Expected behavior
python manage.py dbbackup should work as the path matches?
Screenshots or reproduction
If applicable, add screenshots (errors, example of the behavior, etc.) to help explain your problem or post a link to a repository that replicates the issue.
Versions
django-dbbackup: 3.3.0
Django-dbbackup
External tools

Python: 3.9.6
Django: 3.2.7
wagtail: 2.14.1

For my case, django and postgres runs in different containers. The django container doesn't have postgres-client installed, which causes this error.
My solution is to install latest postgres-client in django container from postgres repo.
I added the following lines to my django container. Place these after any apt-get purge commands.
RUN apt-get update && apt-get install -y wget gnupg2
RUN echo "deb http://apt.postgresql.org/pub/repos/apt bullseye-pgdg main" > /etc/apt/sources.list.d/pgdg.list
RUN wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -
RUN apt-get remove -y wget gnupg2

RUN apt-get update && apt-get install --no-install-recommends -y postgresql-client

Note 1: The reason for using the latest postgres-client from postgresql.org repo (and don't use apt install postgresql-client) is pg_dump checks database version for mismatch. The client must have a higher version than the database. The default postgres-client version in apt is too old (v13) for my database (v14). So I need to get the latest (v15) from the official postgres repo.
Note 2: I used bullseye-pgdg repo, which matches my django container. Modify this to match your container image.
Note 3: I tried to do multi-stage build container to base my django container off postgres image. It requires me to know which files to copy from postgres to django container. I don't know, so I gave up on this method.


Provide clearer error message when repository entry is empty

Fixes #255
The parsing code (get_repos_in_vcstool_format()) already provides a useful error message when an attribute is missing (e.g., url:). However, as shown in the issue above, it doesn't handle/detect empty repository entries. Therefore, check if the repository is empty before trying to access its attributes. Otherwise, provide a useful error message:
$ cat bad.repos
repositories:
  empty_entry:
  missing_url:
    type: git
$ vcs validate --input bad.repos
Repository 'empty_entry' is empty
Repository 'missing_url' does not provide the necessary information: 'url'

Before this change, validation fails on empty_entry (and does not validate missing_url):
$ vcs validate --input bad.repos
Input data is not valid format: 'NoneType' object is not subscriptable

I've also updated the tests to cover this.

friendly ping @dirk-thomas


feat/put-courses

We accidentally deleted our repo and so our PR was also deleted recently, we apologise for the inconvenience

link into our PR Closed => https://github.com/hei-school/hei-admin-api/pull/150


[Bug]: Error code 400 - You must provide a model parameter

What happened?
I was executing my first fabric pattern after installing and setting up, when the Error Code "400 - You must provide a model parameter" happened. I was expecting the API request to return a response to happen instead.
I setup fabric with an OpenAI Key and tried it with ollama as well (changing the default model to openhermes2.5-mistral:latest).
Version check

[X] Yes I was.

Relevant log output
❯ pbpaste | fabric --pattern summarize
Error: Error code: 400 - {'error': {'message': 'you must provide a model parameter', 'type': 'invalid_request_error', 'param': None, 'code': None}}
Error code: 400 - {'error': {'message': 'you must provide a model parameter', 'type': 'invalid_request_error', 'param': None, 'code': None}}

Relevant screenshots (optional)
No response

Check out .config/fabric/.env and see what it looks like. Maybe there’s a typo somewhere

TY


General CI-related maintenance tasks

Run unittests and build doc for both 22.2 and 23.1 backends. This is currently commented out in ci.yml.
Replace PYPI_TOKEN with the token generated for the repo.
Replace .ci\pull_fluent_image.py with a simple bash script. It will pull the Fluent image based on FLUENT_IMAGE_TAG env var and remove all dangling images (docker image prune). Earlier we had limited disk space in the self-hosted runner, so we were cleaning up before pulling the newer image.
As we are going to add more integration tests within the unittests, it is better to split the "Build and Unit Testing" job. We can run unittests in the self-hosted runner and build the package in github runner. We choose to build in github runner to build in a clean machine.

Some of the above tasks are required to be done also in other pyfluent repos. For 1 and 4, we also need to update the list of status checks in repo's branch protection rules.

Hello @hpohekar for this task, please reach out to @mkundu1 for support.

@hpohekar @mkundu1 it will be good to clean up one or two outstanding tasks from this list


changing link on logo

In not self hosted version logo goes to cartodb.com - close #3564

@xavijam CR, please

Looks good! :+1:

Frontend tests were OK :+1: (details)

@xavijam CR again please :)

:jp: :dancer:

Frontend tests were OK :+1: (details)


Phone Number is not working

Already tried to use India (Both Primary and Alternate)

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

ID: 1a2b385a-9cb4-9110-94bb-7d63f7e591f0
Version Independent ID: 07d6eed9-0f79-5c7e-6c7b-0391d0190c57
Content: Support information for India
Content Source: Office365-Admin/support/india.md
Service: o365-administration
GitHub Login: @cmcatee-MSFT
Microsoft Alias: cmcatee

I'm working on verifying that the #s are correct & working. Will update when I know more.

@jerikkofrancisco & @tumud  - thank you for submitting feedback.
I think the best way forward is if you can open a service ticket in your tenant so this can get resolved ASAP. Based on outcome let me know if it is something that can be called out in the docs.
Here is a quick video on opening a ticket: https://www.youtube.com/watch?v=puuOy0sEg1Y

@jerikkofrancisco & @tumud - We have confirmed that the phone numbers stated in the MS Article are correct. However, there is a technical issue in the backend that is being resolved. Rest assured that this is being worked on.
Thank you for submitting this feedback. We appreciate your contribution to make the docs better.


try different gcm enabled

Following a different suggestion in the issue https://github.com/evernote/android-job/issues/415 to fix the background crashes implemented here: https://github.com/nextcloud/android/pull/2650.
@AMarcedone says he hasn't noticed anything, might be best to merge this and monitor on more staff devices before potentially doing a hotfix release. I haven't been able to reproduce with the android simulator

@thebearjew

Follows GCM's manifest permissions for the service and intent-filter, looks good to me: https://developers.google.com/cloud-messaging/network-manager


Add support for aggregate counters

My goal was to create a solution that would allow for counting groups of things w/o having to add additional counters to the client code.

Ryan, this looks a lot like dimensions where you publish a counter/timer/gauge and then attach one or more key-value pairs to it. The value(s) published under that metric are aggregated under the cross-product of the dimensions.
For example:

metric"response", value=1, result="400", family="4xx"
metric"response", value=2 result="404", family="4xx"

The result would be aggregates:
response [result=400, family=4xx] = 1
response [result=404, family=4xx] = 2
response [result=ALL, family=4xx] = 3
response [result=400, family=ALL] = 1
response [result=404, family=ALL] = 2
response [result=ALL, family=ALL] = 3
This preserves the attribution and allows it to be mapped to the data store without necessarily making a new metric for each one. For example, if the volume on some subset of dimension key-value pairs is below a threshold they can all be collapsed into "OTHER" for dimension keys that vary across that subset.
I understand at the moment we don't support dimensions in the client (or aggregation stack) and if this pattern works for you I suggest we work together to create an extension. However, I am not inclined at this time to package this with the core client. Happy to discuss this further.


[Bug]  Loading RM images locally throws error

Describe the Bug
Problems when opening studies of the MR modality in the other modality if it opens well, only in version 3.9 in versions 3.8 and 3.7 if the MR opens without problems

Steps to Reproduce
using image ohif/app:v3.7.0 and ohif/app:v3.8.0
and changing the config.js to my dcm4chee this:
    wadoUriRoot: 'https://my.server/dcm4chee-arc/aets/DCM4CHEE/wado',
    qidoRoot: 'https://my.server/dcm4chee-arc/aets/DCM4CHEE/rs',
    wadoRoot: 'https://my.server/dcm4chee-arc/aets/DCM4CHEE/rs',

Everything works perfectly for me, it lists studies and I can open all the modalities without any problems.
The problem arises when changing to the version
ohif/app:v3.9.1
It lists the studies without problem and I can open all the modalities without problems except the MR modality, it gives me the error.
Note: if I leave the default url of the OHIF demo if it opens those MR
The current behavior
Every time I try to open any MR in version 3.9 I get the error, the other modalities do work well
The expected behavior
I expected the study to open without problems since the other modalities open, and in versions prior to 3.9 the MR also opened
OS
ubuntu 22.04
Node version
docker image 3.9.1
Browser
all explorer

Can you provide anonymized data?


Generated GREYAction JS wrapper uses unsupported variable types

The newly added GREYActions generated code relies on invocation features we don't support natively.
For instance here we use GREYDirection (which is just an ENUM). On the original implementation we us NSInteger to invoke the method.
Description
Here's the invocation action that is sent when using the old method:
{"type":"invoke","params":{"target":{"type":"Invocation","value":{"target":{"type":"EarlGrey","value":"instance"},"method":"detox_selectElementWithMatcher:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYMatchers"},"method":"detoxMatcherForScrollChildOfMatcher:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYMatchers"},"method":"matcherForAccessibilityID:","args":["ScrollView161"]}}]}}]}},"method":"performAction:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYActions"},"method":"actionForScrollInDirection:amount:","args":[{"type":"NSInteger","value":4},{"type":"CGFloat","value":100}]}}]},"messageId":5}
Here's the invocation action that is sent with the new generated code
{"type":"invoke","params":{"target":{"type":"Invocation","value":{"target":{"type":"EarlGrey","value":"instance"},"method":"detox_selectElementWithMatcher:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYMatchers"},"method":"detoxMatcherForScrollChildOfMatcher:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYMatchers"},"method":"matcherForAccessibilityID:","args":["ScrollView161"]}}]}}]}},"method":"performAction:","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"GREYActions"},"method":"actionForScrollInDirection:amount:","args":[{"type":"GREYDirection","value":4},{"type":"CGFloat","value":100}]}}]},"messageId":5}
The difference is {"type":"NSInteger","value":4} vs {"type":"GREYDirection","value":4}
Steps to Reproduce
in ios/expect.js, change
this._call = invoke.call(invoke.IOS.Class('GREYActions'), 'actionForScrollInDirection:amount:', invoke.IOS.NSInteger(direction), invoke.IOS.CGFloat(amount));

to
this._call = invoke.callDirectly(GreyActions.actionForScrollInDirectionAmount(direction,amount));

and also, remark the switch on direction.

These are the currently supported types:
EarlGrey, Class, NSString, NSNumber, NSInteger, CGFloat, CGPoint, CGRect and Invocation

We do need to refactor the MethodInvocation part to be more flexible, but for the time being, these are our limitations.

This is actually just a small bug, will provide a fix for it. In the other hands this leads to the discussion on how to fix unsupported types being used.
The current approach is to add sanitizers (e.g. sanitize_GREYDirection) and I think it would be best to go this path until the end and change the invocation scheme to support arbitrary inputs afterwards.
My plan for this would be to

List all supported typed, like @rotemmiz already did
Filter the methods before building the AST (this would be the right place to start)
Add a console.info anywhere here that does the opposite filter and list out which methods / types are currently unsupported.

We could also think about it the other way around and check the generated code for any types other than the ones whitelisted, that way we could be sure to spot typos too.


Link, unlink request methods

It would be great if koa-router supports link and unlink request methods on default

koa-router uses methods so it has to be added to that module.

LINK and UNLINK aren't RFC Standards Track methods and node core (joyent/http-parser#157)


Create attachment from emails

needs following changes as well

https://github.com/VacsoLLC/frameworkTicketing/pull/3


add writev_all to io modules

And add File::writev_at_all as the first user facing example.
The writev_all function will call the io_uring writev operation as many times as necessary to get all the bytes written or to hit an error, which ever comes first.

@mzabaluev The same function will be called from TcpStream and UnixStream so a common place like the io directory seemed reasonable to me.


Studio: Fixed device overflow on window resize

Issue: The device's size expanded disproportionately when the window was resized.
Solution: Adjusted the styling by setting flex-grow to flex-1 and positioning inner elements as absolute.

Nice! Tested locally and it works great!
(For future reference: a screen recording would've been helpful here to show the fixed behavior)


When rename the sheet it removes the chart data from sheet.

Description
I am trying to create a chart on excel sheet using AddChart() function. I executed the code successfully and It returned me the file as I am expecting it to be. But when before saving the file I want to rename the sheet name using xlsx.SetSheetName("Sheet1","New Name") It creates a file with empty chart.

Steps to reproduce the issue:

Write following code and check the output it will return the correct chart with Graph.

package main
import (
    "fmt"
    "github.com/360EntSecGroup-Skylar/excelize"
)

func main() {
    categories := map[string]string{"A1": "datum", "A2": "19-Nov-2018", "A3": "20-Nov-2018", "A4": "21-Nov-2018", "A5": "22-Nov-2018", "A6": "23-Nov-2018", "A7":"24-Nov-2018", "D1":"score totaal/h"}
    values := map[string]float64{"D2": 3.0047, "D3": 3.3697, "D4": 2.7776, "D5": 1.5615, "D6": 2.5649, "D7": 4.3659}

    xlsx := excelize.NewFile()
    for k, v := range categories {
        xlsx.SetCellValue("Sheet1", k, v)
    }
    for k, v := range values {
        xlsx.SetCellValue("Sheet1", k, v)
    }

 xlsx.AddChart("Sheet1", "B13", `{"type":"line","dimension":{"width":480,"height":600},"series":[{"name":"Sheet1!$D$1","categories":"Sheet1!$A$2:$A$7","values":"Sheet1!$D$2:$D$7"}],"format":{"x_scale":1.0,"y_scale":1.0,"x_offset":15,"y_offset":10,"print_obj":true,"lock_aspect_ratio":false,"locked":false},"legend":{"position":"bottom","show_legend_key":false},"title":{"name":"Fruit 3D Clustered Column Chart"},"plotarea":{"show_bubble_size":true,"show_cat_name":false,"show_leader_lines":true,"show_percent":true,"show_series_name":true,"show_val":true},"show_blanks_as":"zero","x_axis":{"reverse_order":false},"y_axis":{"maximum":50,"minimum":0}}`)

    // Save xlsx file by the given path.
    err := xlsx.SaveAs("./Book1.xlsx")
    if err != nil {
        fmt.Println(err)
    }
}

Add the following line before saving the file
    xlsx.SetSheetName("Sheet1","customsheetname")
and it will save the file with empty chart.

Output of go version:
go version go1.9.4 linux/amd64
Excelize version or commit ID:
9a6f66a996eb83f16da13416c5fca361afe575b0
Environment details (OS, Microsoft Excel™ version, physical, etc.):
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial

hi,
chart data is not appearing also if you place a different string than 'Sheet1' in SetCellStyle or SetCellValue.

Hi,
I encountered the same issue that the chart does not show any data.
I cannot confirm that removing the Sheet1! prefix in the settings will help. (For testing un-comment the code line // format := ...)
I can also not confirm that it will only work on Sheet1.
From my point of view it looks like there is an issue with sheet names that contains blanks.
I took the code from the examples and modified it to illustrate the behavior.

import (
	"fmt"
	"strings"

	"github.com/360EntSecGroup-Skylar/excelize"
)

func addChart(f *excelize.File, sheetKey string) {

	categories := map[string]string{"A2": "Small", "A3": "Normal", "A4": "Large", "B1": "Apple", "C1": "Orange", "D1": "Pear"}
	values := map[string]int{"B2": 2, "C2": 3, "D2": 3, "B3": 5, "C3": 2, "D3": 4, "B4": 6, "C4": 7, "D4": 8}
	for k, v := range categories {
		f.SetCellValue(sheetKey, k, v)
	}
	for k, v := range values {
		f.SetCellValue(sheetKey, k, v)
	}

	format := strings.Replace(`{"type":"col3DClustered","series":[{"name":"Sheet1!$A$2","categories":"Sheet1!$B$1:$D$1","values":"Sheet1!$B$2:$D$2"},{"name":"Sheet1!$A$3","categories":"Sheet1!$B$1:$D$1","values":"Sheet1!$B$3:$D$3"},{"name":"Sheet1!$A$4","categories":"Sheet1!$B$1:$D$1","values":"Sheet1!$B$4:$D$4"}],"title":{"name":"Fruit 3D Clustered Column Chart"}}`, "Sheet1", sheetKey, -1)
	// if a remove the sheet prefix 'sheet!' not data at all will be displayed in the chart
	//format := strings.Replace(`{"type":"col3DClustered","series":[{"name":"Sheet1!$A$2","categories":"Sheet1!$B$1:$D$1","values":"Sheet1!$B$2:$D$2"},{"name":"Sheet1!$A$3","categories":"Sheet1!$B$1:$D$1","values":"Sheet1!$B$3:$D$3"},{"name":"Sheet1!$A$4","categories":"Sheet1!$B$1:$D$1","values":"Sheet1!$B$4:$D$4"}],"title":{"name":"Fruit 3D Clustered Column Chart"}}`, "Sheet1!", "", -1)

	err := f.AddChart(sheetKey, "E1", format)
	if err != nil {
		fmt.Println(err)
		return
	}

}

func main() {
	sheets := []string{"AnotherSheet", "A Sheet with blanks"}

	f := excelize.NewFile()

	for _, sheet := range sheets {
		f.NewSheet(sheet)
		addChart(f, sheet)

	}

	addChart(f, "Sheet1")
	// Save xlsx file by the given path.
	err := f.SaveAs("./Book1.xlsx")
	if err != nil {
		fmt.Println(err)
	}

}

The code makes a new xls-file and adds three sheets with the sample chart and the last sheet does contain any data in the sheet. Sheet names with blanks works fine for SetCellValue but not for f.AddChart. Hope this provides more detail.


python version upgrade

Description
Upgraded python version from python3.8 to python3.11
Motivation and Context
To mitigate vulnerabilities in python3.8
Types of changes
Modified one line in dockerfile
Checklist
Need to test with a FIP or FIU

@gsasikumar Please review and merge

@gsasikumar , Hi I am GB. I worked with Renuka on this. We weren’t sure of the side effects it would have by upgrading the base image. From jdk version to dependencies that would change. Do you still recommend upgrading the base image instead? Plus the base image is not just alpine right? It’s some Zulu image based off of alpine. Open to hear your thoughts.


fix: Reset password schema

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#51  👈
#43 : 1 other dependent PR (#46 )
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tamrivera05 and the rest of your teammates on  Graphite


[component] Tooltip Icon

Notes for Reviewers
This PR fixes #376
Signed commits

[ ] Yes, I signed my commits.

oh okay got it, i made pr i thought it was required for that same quick

I will make this tooltip as the tooltip we use for information across modals

@sudhanshutech you didn't answer @nebula-aac's question.

I will make this tooltip as the tooltip we use for information across modals

@sudhanshutech you didn't answer @nebula-aac's question.

yes, its done now

@sudhanshutech there are two different tooltips being used in Meshery UI.
@iArchitSharma should have recently filed an issue on this that he can link here. Let's consolidate to the better looking of the two, which should be the Sistent tooltip. Hopefully, this is the good-looking tip.

Link to issue - https://app.clickup.com/t/86cuqu3qm
@sudhanshutech

thanks @iArchitSharma i will take a look on the task


capistrano corrupted terminal output

I am working on deploying 3 servers with capistrano, rvm, ruby1.9.3, rails3.2.1. While setting up, I ran (. capify) on one of the servers and it complained about a version mismatch between my local and the server.  local-2.11.2   server- 3.4. I upgraded the local machine to 3.4 and ran a cap deploy. Doing so corrupted my terminal output. The output no longer comes out in neat little rows and displays like it has random tabs throughout making it harder to read. So I downgraded each version back to 2.11.2 and did a bundle install. Now, when I run cap deploy instead of asking for the password once for 3 servers it asks 5-7 times and usually fails with Authentication failed for user... I did a 'reset' in the terminal which seemed to correct some of the indentation issue, but definitely not all. (echo -e "\xF") did not do much either.

Just a little more info. When I run
. capify
on the remote server it now returns:
require: command not found
version: command not found
bash: /usr/local/bin/capify: line 15: syntax error near unexpected token (' bash: /usr/local/bin/capify: line 15:   str = str.dup.force_encoding("BINARY") if str.respond_to? :force_encoding'

No one has any suggestions? This is very annoying.

I'm sorry you are not being coherent and I can't understand what you are doing, or anything you are attempting to say. I have no idea why you would be running . capify you appear to be corrupting your own shell.
Whatever you are doing forcing binary encoding is also probably not helping the situation. This is clearly not a bug in Capistrano else you would see other reports of it here, rather something you are doing wrong, come and talk to us in our Google Group support forum.


Is it possible to disable the section labels?

Hopefully this is the right place for this sort of thing.
Is there a way to turn off the section labels? I've tried any parameters that seemed related but I have not been able to turn them off.
section-label=false makes the section labels start at the character f (or whatever the first character is for the parameter value).

That sure sounds like a bug. I'll investigate this weekend.

I'm confused about section-label. AFAICT, that's not an xslTNG parameter. Although your description of what happens when you set it suggests that something happens. What version of the stylesheets are you using?
xslTNG 1.x
For the xslTNG 1.x releases, you can make the section labels go away by changing the title properties:
<xsl:variable name="v:user-title-properties" as="element()*">
  <title xpath="self::db:section"
         label="false"/>
</xsl:variable>

Or, if for example, you only wanted them to go away in chapters, you could use
<xsl:variable name="v:user-title-properties" as="element()*">
  <title xpath="self::db:section[parent::db:chapter]"
         label="false"/>
</xsl:variable>

xslTNG 2.x
For the xslTNG 2.x releases, you can make the section labels go away by changing the localization:
<xsl:variable name="v:custom-localizations">
  <locale xmlns="http://docbook.org/ns/docbook/l10n/source"
          language="en"
          english-language-name="English">
    <group name="list-of-titles">
      <template name="section">%c</template>
    </group>
    <group name="title-numbered">
      <template name="section">%c</template>
    </group>
  </locale>
</xsl:variable>

Or, again, if you only wanted them to be missing in chapters, you could use:
<xsl:variable name="v:custom-localizations">
  <locale xmlns="http://docbook.org/ns/docbook/l10n/source"
          language="en"
          english-language-name="English">
    <group name="list-of-titles">
      <template name="chapter/section">%c</template>
    </group>
    <group name="title-numbered">
      <template name="chapter/section">%c</template>
    </group>
  </locale>
</xsl:variable>

Note in this case that the name is not an XPath expression.
It's probably a bug that you have to set it in two places. And maybe it's a bug that the name isn't as poweful an expression.
The 2.x series is still in pre-release, so it's subject to change.

I'm going to close this, but feel free to reopen it if you haven trouble with those instructions.


[Feature Request] Support query for temporal schedule list

Support query for temporal schedule list using this new field: https://github.com/temporalio/api/blob/6cd92a2f214a2d14872af81e31b6eee2f8b745ca/temporal/api/workflowservice/v1/request_response.proto#L1157

This is actually needed everywhere, not just CLI. Opened https://github.com/temporalio/features/issues/505.


Add ability to run manage from the serve command

This commit adds the ability to run zed manage in the same process as the zed serve command. If the -manage flag is set with a duration greater than 0 manage will run.
This commit also move the manage package to lake/api/manage package and simplifies the logic for the monitor function.

I'd like to have @philrz give this a spin before we merge it.

Agreed.

I just tested this branch out at commit 9ce0f4f and it seems to work fine. One thing I found a little odd though is that I went looking for a ztest in this PR since that usually gives me a starting point for seeing how the new functionality is invoked and it looks like the only ztest change is to something that only exercises the pre-existing approach that used the zed manage approach. Does the continuous nature of zed serve -manage make it too difficult to hit with ztest?

After an offline discussion with @nwt he agreed to take up the testing angle separately/later via what's now tracked in #5024.


intial Default selection not working

When view is first loaded it defaultly take take first index,But it is not selected .,Can u please help?

You must select that row yourself.


Benchmark you can add - Mac Mini 2023 - Apple M2 Pro - 32gb ram - os - 15.0

Note: Does freeze system :)
Looped 10 times in a row
time_output=$( { time mflux-generate --model schnell --prompt "Luxury food photograph" --steps 2 --seed 2 -q 8 --height 1024 --width 1024; } 2>&1 )
63.849
57.555
50.578
54.900
52.251
50.690
53.887
51.434
52.421
52.772
Average time - 54s.
Great work btw.

oh just saw the exiftool comment, let me get that..
filename,generation_time
image_10.png,42.15
image_11.png,39.21
image_12.png,38.78
image_13.png,39.86
image_4.png,38.97
image_5.png,53.22
image_6.png,41.76
image_7.png,39.54
image_8.png,38.94
image_9.png,38.87
41.13s average.

@leekichko Thanks for the numbers. I'll report your first number to make the comparisons a bit more fair since the exiftool actually measures it a bit differently (it skips the text-encoding parts that happen before the main loop).
Also quite good numbers - At first I was surprised that it was faster than this one https://github.com/filipstrand/mflux/issues/11 (M3 Pro with 36 GB), but then I guess there are a lot of details we don't know about the other benchmarks such as number of GPU cores etc. A newer mlx, macOS 15, etc. could also contribute to the speed. Anyways, great to get your measurements here!

@leekichko Thanks for the numbers. I'll report your first number to make the comparisons a bit more fair since the exiftool actually measures it a bit differently (it skips the text-encoding parts that happen before the main loop).
Also quite good numbers - At first I was surprised that it was faster than this one https://github.com/filipstrand/mflux/issues/11 (M3 Pro with 36 GB), but then I guess there are a lot of details we don't know about the other benchmarks such as number of GPU cores etc. A newer mlx, macOS 15, etc. could also contribute to the speed. Anyways, great to get your measurements here!

If you want any other details let me know. Happy to support projects like this.


Make GetUserReference pointer argument const

canardGetUserReference doesn't actually modify the CanardInstance given as argument.

@tridge Hello, what is blocking this getting merged?


Where clouse not worknig when using relations columns

Hello,
I'm facing an issue when trying to fetch items using the where clouse, but using a column from the relation
Tables
User
Items
Relations
Users -> one to many -> item
code
const paginatedResult = await paginate(query, this.itemRepository, {
    relations: ["user"],

    select: ["id", "name", "user.id", "user.username", "createdAt"],

    where: {
        user: { username },
    },

    sortableColumns: ["createdAt"],
    nullSort: "last",
    defaultSortBy: [["createdAt", "DESC"]],
    filterableColumns: {
        createdAt: [FilterOperator.GT, FilterOperator.LT],
    },
});

Error
Error: Cannot find alias for relation at user
My conclusions
I googled the error, and I find out that this is a typeorm error that happens when you use a relation column in a where clouse, wihtout specifying the relations, you can check the issue here
Am I doing something wrong or is this a bug?
Thanks in advance

umm, just checked. test suite only covers many-to-many for nested where. so could be a bug.
can you share the generated SQL query?

umm, just checked. test suite only covers many-to-many for nested where. so could be a bug.
can you share the generated SQL query?

Hello, thanks for your fast response, how can I get it ?

I tried with the user id and it worked

ok closing this issue then


Extra large file upload and appears throttled somehow

I'll start off by saying this could be an issue on my part because I'm still getting used to Linux/Ubuntu/Docker Compose.
Setting up PingVin on my dedicated server was extremely easy. When I upload a 5GB .zip to the PingVin server from my own PC, the upload speed is limited to about 4Mb/s. When downloading the same 5GB .zip from the PingVin the download speed is limited to about 50 Mb/s.
Speedtest performed on the same server through cli and docker run give a stable 950 Mb/s. I noticed a perhaps similar issue was closed recently.
If there is anything I can tweak myself, or do to provide you with more complete information, please let me know.

On second thought and continued investigation this is probably a me-issue after all, monitored tcp connections for port 3000 for both a 0.3GB and 5GB file but there was barely any difference. There are not a lot of simultanous TCP connections and their speed rate is slow to  climb before they get closed, it appears the actual upload speed to server may be around 0.5-2Mb/s but at least it's not because of PingVin as far as I can tell. If anyone has suggestions on where to look next please let me know before the issue is closed.

Thanks for your report! It's really difficult to debug this. Maybe you could install Pingvin Share on the same machine as you upload the files (for testing purposes), if there is no throttling it must be an issue with your server.

Closing this because of inactivity. Feel free to reopen the issue if you still have the problem


Disk Space recommendation for Thanos Store Gateway

Quick question:
How do I estimate the amount Thanos Store Gateway disk size based on the amount of retention I need? Does it pull and cache metrics locally or does it only store index?

On boot, Thanos Store builds the binary index header of each block & stores them on disk: https://thanos.io/tip/operating/binary-index-header.md/. So, it depends on how big the blocks are. If the number of metrics that you ingest over time is roughly the same then you could multiply the size of one binary index header by the number of the blocks that you have to estimate the disk size requirement.

Yes it does, thank you very much


re build

I was building without node-fetch
https://github.com/Doarakko/action-lgtmoon/issues/3

test
https://github.com/Doarakko/action-lgtmoon/pull/4#pullrequestreview-929711483


Fix issue while editing model serving model

Description

Fix an issue where assembling error token names was misconfigured
How Has This Been Tested?

Create a new Model Server (Serving Runtime)
Edit values
Check that is working

Test Impact

Request review criteria:

[X] The commits have meaningful messages (squashes happen on merge by the bot).
[X] Included any necessary screenshots or gifs if it was a UI change.
[X] Included tags to the UX team if it was a UI/UX change.
[X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[X] The developer has manually tested the changes and verified that the changes work
[X] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

/lgtm

Tested and works as expected!