Is the complexity of this module getting too high?

A general question for users and contributors of this module 🙂
My feeling is that complexity getting too high and quality is suffering somewhat. We are squeezing a lot of features in a single module. This is by far the most complex module in the Terraform AWS modules org. But perhaps I just feel the pressure since I'm a maintainer?
Some recent examples:

Adding global create_eks variable: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/580
Adding Managed Node Groups: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/602
Use kubernetes provider: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/355
Add Windows support: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/555

And now:

Adding IRSA: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/632
Adding Fargate profiles: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/634

The amount of new resources being added to this module is just getting higher. And I don't see this slowing down as AWS is doubling down on EKS, as is everyone on k8s in general.
Don't get me wrong, these are all awesome contributions 💙 but I feel there's a price here. On every new release there's always bunch of new issues related to the recent changes.
Let me know your thoughts 😃

Yep. I've felt this way for quite a while now. And it's it's already too late. Too many new "features" have been added without letting things settle down and stabilize.
And, it's not fair to you as the maintainer, or to me as the user trying to run this thing in production. I'm cringing right now thinking about upgrading my prod cluster to v7.x. There's just no way I can reasonably safely do it.
IMO: deprecate this module and make several smaller, focused ones. Think long and hard about each new addition. Solicit feedback from multiple sources before leaping into a new feature. Even if somebody shows up with a PR with it all done if it ups the complexity of the module that should be considered carefully.
Another idea I have is to stop trying to support windows. There are unfortunately instances where a local_exec needs to run, and lots of complexity has been added trying to support windows alongside *nix. Instead, we can say "this is supported by linux (and probably mac). If you are on Windows, here is instructions on how to run this thing in a docker container.

Examples of small, focused modules:

Worker group module, separate from the main module(s)
Main EKS Cluster module
Fargate k8s module

At a bare minimum, documentation should be added for each new feature. On top of just adding the new params in the table. But I don't think that's going far enough to solve the predicament this module is already in.

I agree with ditching the support for windows as local_exec is required sometimes. and every new feature should have its own documentation, params, examples, and switch flag.

First, thank you @max-rocket-internet for maintaining this module for everyone.
As far as complexity I would agree this module is certainly complex but I would not expect much less when trying to maintain both halves of a managed Kubernetes Cluster. It is also very reasonable to assume it will only get more complex based on the AWS roadmap.
As for paths forward I agree with @RothAndrew and @alaa  in regards to documentation and dropping windows support for now.
As for the module itself, I would hate to see this module depreciated after seeing it come this far. It would be better in my opinion to determine the direction it should go and instead work towards that as a community. It certainly does make sense to shard the module out in a way but unfortunately no matter how you look at it they will always be co-dependent on one another. I struggle to visualize a world where I would use an eks-fargate module without using eks-cluster along side it. That being said separating cluster configuration from worker configuration by means of a sub module may be a more manageable way to handle feature creep.
To add to this, if there is any way I as an individual can lend a hand I would certainly love to be more involved.

I'm going to voice the other side of the no-Windows argument: local-exec should be banned from within the module now that's its gone:

Its use makes supporting Windows difficult. Both for maintainers blindly guessing at support and for users
It requires installing extra tools. We heavily use terraform inside short lived CI containers. Maintaining extra CI images is a pain. Or we waste time every run installing extra commands that might not be called. Ideally we should only need pure terraform.
They have long been a source of issue and bugs.
local-exec also makes the module difficult to use on terraform cloud where extra tools are also not available. You need more local-exec hacks to get them installed first. #226
I don't think there's anything on master right now that's blocking Windows users?

Maybe splitting up in to sub modules would isolate some of the complexity rather than running as a single flat layer? Similar to how the RDS module is designed. Upgrade paths will be painful to get to that state, of course. And the aws-auth map will always add complexity for submodules that create workers.
Submodules could either be directly used by the top level as required (RDS style) or as version linked partner modules that users include as necessary, similar to how security-group works. Would need much documenting and examples in the second use case though due to aws-auth.
I think trying to coordinate stand-alone intertwined modules will be a maintenance and user nightmare. But it's not something I've tried.
Burning the module and starting again will present its own problems. There will still need to be some upgrade path for users who used this module. aws_eks_cluster is not a flexible resource. The master IAM role name is an example of something people wanted to change but existing users are locked in to.
Could something be done to increase release velocity? But without swamping Max with administrative tasks?

master only receives bug fixes for stable features. And regular point releases. The VPC and RDS modules receive a point release after every merge of bug fixes or trivial changes.
exciting new or breaking features, like kubernetes provider, are kept in a branch for testing and fixing. Before finally merging to master once settled enough and a major release.

Burning the module and starting again will present its own problems

I would hate to see this module depreciated after seeing it come this far

To be clear, I'm not thinking we should do either of these, I was just thinking perhaps we could restructure or split parts of it 🙂

Another suggestion: start rejecting PRs that want to introduce breaking changes that aren't providing great documentation on how to upgrade and preferably automated migration.

Splitting it up into submodules like RDS does seems like a really good idea. However, unless Terraform supports easy migration of resources that I don't know of, it seems like this would require a significant effort to migrate existing projects to the new version of the module. 😞
Even if it gets split, some PRs, such as #555 and #580, would require similar changes as they did now, since they affect multiple modules.
At the moment, I'm really interested in IRSA and Fargate support, since we currently resort to specifying those resources outside of the module. Maybe we can start with adding those two as a separate submodules? They don't depend on much apart from eks instance.
If I can help with getting these features merged (e.g. help with splitting, writing examples), please let me know.

While refactoring projects because the eks module changes (or goes away) will be a pain for those who depend on it, the module should not be held prisoner by it. A possible path: deprecate the current module, and fix only security and critical functionality problems. Create new module(s) which break up the parts (eks, node groups, etc). This will avoid breaking existing users, but will make a cleaner path forward. Existing users can pick when they spend the time to switch to the new hotness.

Deprecate this module will be a nightmare for existing users, I can't imagine i need to delete current clusters then recreate them using new modules or import all resources to new modules.I'll feel less pain if we could continue to maintain this module and deprecate and move features to smaller modules gradually.

OK here's my thoughts...

IMO: deprecate this module and make several smaller, focused ones.

This was my initial thought also.

Solicit feedback from multiple sources before leaping into a new feature. Even if somebody shows up with a PR with it all done if it ups the complexity of the module that should be considered carefully.

I like this idea but there's no one to do it apart from maintainers. People want their PRs merged but they rarely want to review other PRs (apart from @dpiddockcmp)

I agree with ditching the support for windows

Cool. I think so too. But this only solves local_exec issues AFAIK.

Maybe splitting up in to sub modules would isolate some of the complexity rather than running as a single flat layer?

Yes. I was thinking perhaps modules for:

The cluster including aws-auth configmap
Fargate
Managed Nodes Groups
Normal worker groups

I think trying to coordinate stand-alone intertwined modules will be a maintenance and user nightmare

I think so too. I don't have enough time for this module let alone a bunch of others.

Could something be done to increase release velocity? But without swamping Max with administrative tasks?

We need more maintainers. It's as simple as that. I have less time these days.

Another suggestion: start rejecting PRs that want to introduce breaking changes that aren't providing great documentation

That's a great idea.

At the moment, I'm really interested in IRSA and Fargate support, since we currently resort to specifying those resources outside of the module.

Sure but AFAIK IRSA is only a single resource? https://github.com/terraform-aws-modules/terraform-aws-eks/pull/632/files

Maybe we can start with adding those two as a separate submodules?

@antonbabenko please chime in. I think we should consider creating some new modules to split out some of the functionality of this module. Personally I think separate github repos but not really up to me.

Here are my 5 cents, though I have not used or followed the development of this module closely for some time - I feel that everyone who commented on this page is already on the same page (lol).
The complexity of this repository is large but still controllable because of the good patterns used here. Good job, everyone!
I don't think that splitting this module into submodules or separate repos for Fargate, Managed Nodes  Group, Normal Worker Groups, etc will give any benefits to users and maintainers who will have to manage similar EKS-related-things in multiple places.
I also don't think we need to add more maintainers, because most of the time is usually spent on answering issues and triaging bugs, and this can be done by anyone. Adding more people will not increase velocity, but releasing more often (after every PR is merged) will.
If there is not an obvious feature, consider adding examples show-casing it. Same for bugs if they keep reoccurring.

To me this module is quite complex, but it's still maintainable and readable.
I'm not against splitting this module into submodules, but I'm against any kind of code duplication and the really annoying migration path. Furthermore, I'm not really confident this will help.
Thinking out loud, I would say we have a lack of automated tests which can tell us easily if a new feature introduce bugs or regressions. If a change breaks something. Features will came quickly as kubernetes and EKS are evolving really fast, and people will always want to get those feature as quick as possible. There is no way to do that without automation. I know it's a long way to go, and I don't really know how we can achieve that goal with free resources, but I think it's worth digging a little deeper.

I also don't think we need to add more maintainers, because most of the time is usually spent on answering issues and triaging bugs

I don't spend much time on issues these days. I will also have less time in the future.

Thinking out loud, I would say we have a lack of automated tests

Very true. Hard to achieve without spending money though.
We now have 4 ways of creating workers:

Worker groups with LC
Work groups with LT
Managed node groups
Fargate https://github.com/terraform-aws-modules/terraform-aws-eks/pull/634

I think 1 and 2 can be merged now with TF 0.12. But 3 and 4 are very different, perhaps they could be put into modules/xx and then examples added for how to use them? This then reduces the complexity in all the complicated conditions around cluster creation, iam roles etc.

I think in a healthy ecosystem there can be multiple good ways of doing it. I think much of the success of the terraform-aws-modules/terraform-aws-eks module is due to its ability to get a user up and running quickly, plus it's packed with features. Someone brought up how changing this now could be rather disruptive to a large number of users and I agree.
Fwiw, we took the alternative approach presented in this ticket:

cloudposse/terraform-aws-eks-cluster takes care of the master setup
cloudposse/terraform-aws-eks-workers will provision an ASG with EC2 nodes
cloudposse/terraform-aws-eks-node-group provisions a managed node pool
cloudposse/terraform-aws-eks-fargate-profile adds fargate support

I think this approach lends itself to those who want more control over the architecture of the kubernetes cluster itself. We've also wired it up with terratest because we also struggled to validate user-contributed changes (PRs) fast enough. The downside is that it requires the user to have more of an opinion on what the architecture should look like.
For our use-case, the approach has worked well because it allows for any combination of node pools in pretty much any possible configuration, without increasing complexity and the risk of regressions. I think soon we'll be adding support for SpotInst ocean node pools as well, as we've had good success using that with kops.

A lot has already been mentioned.

Speed and quality of development seems to suffer from increasing complexity.
No automated tests to mitigate that.
Because of fast moving eco-system (Kubernetes and EKS), there will be no stabilizing as new features keep coming.

I think a lot of the complexity boils down to the increasing number of possible ways to create worker nodes, that all share the same underlying code.
Also from a user-perspective it becomes increasingly hard to determine what can be defined in workers_group_defaults, what workers_group_defaults options are supported by the various ways to create workers, etc.
Separating out the 4 current ways to create workers into separate submodules would I think help maintainability without needing to alienate current user-base:

There can be a roadmap. Add submodules, allow people for a period to create equivalent resources using the submodules. Only then remove from core module. (After all, worker nodes are pets, at some points workloads need te moved around at some point anyway)
Separate release cycles will help both maintainers as well as users needing to upgrade.
Smaller surface area to test (less regressions)

Splitting into some sub modules seems like a popular idea in this issue so how about this plan?
To do now

Managed node groups (MNGs) are new, not in any release and currently has a few bugs in master. Let's move all of this into a submodule (in this repo) and update the example.
Fargate can follow the same idea and go into a submodule.

This will move any complexity from MNGs and Fargate out of the core of this module and doesn't break any backwards compatibility.
To do soon

Merge LC and LT worker groups https://github.com/terraform-aws-modules/terraform-aws-eks/issues/563

Then perhaps later down the line we could move LC/LT worker groups into a separate module if it looks like a good idea.

@max-rocket-internet Sounds like a plan.
At least something to start exploring. Start and see what challenges we run into. Having actual code to evaluate.
E.g. managing aws-auth might be a 'thing' as generated roles are no longer in the core. So perhaps managing aws-auth should be extracted to.

Another suggestion: start rejecting PRs that want to introduce breaking changes that aren't providing great documentation on how to upgrade and preferably automated migration.

I've noticed a significant build up of non-breaking changes and new features under [v8.?.?] - 2019-??-??] in the changelog. IMO we should strive to release these as part of a minor increment so that they are (1) available earlier and (2) can be used by developers who aren't ready to deal with all the unrelated breaking changes.

I agree an think it has become to complex.
Breaking the module apart and allowing for smaller modules focusing on different parts is ideal.
I have been for example reviewing how to add an IAM policy to workers.
thanks for the hardwork.

Submodules are great for keeping your code DRY when you need to do the same thing multiple times, however when only called once they have the opposite effect and actually increase code duplication. Turning node groups into a submodule is a great example of this: You still have all the code that would otherwise be in node_groups.tf, plus duplicate code for outputs.tf and variables.tf, plus the extra code for calling the submodule itself.
This would be a very different case if Terraform allowed for_each loops and count when calling submodules, however unfortunately they are very much second-class citizens in Terraform 0.12.
The complexity of this module is generally proportional to the complexity of AWS' Kubernetes implimentation. The reason it has four ways of creating modules is because AWS has four ways to do so, with significant inconsistencies between them. IMO a huge part of this module's value is that it can reduce these inconsistencies by abstracting away complexity such as how eks node groups use the remote_access block instead of just using key_name like in launch configurations.
I'd like to propose an alternative solution for reducing complexity: Sane defaults. For example:

Are all four ways to launch worker nodes actually necessary?
How often will people use EKS but not want the ability to assign IAM roles to pods, which is what IRSA allows?
Why would a user want manage_aws_auth = false given that the same thing can be accomplished by just leaving map_accounts, map_roles, and map_user undefined?

Another suggestion: start rejecting PRs that want to introduce breaking changes that aren't providing great documentation on how to upgrade and preferably automated migration.

I've noticed a significant build up of non-breaking changes and new features under [v8.?.?] - 2019-??-??] in the changelog. IMO we should strive to release these as part of a minor increment so that they are (1) available earlier and (2) can be used by developers who aren't ready to deal with all the unrelated breaking changes.

Sounds like there are 2 things here that can be done:

Stop or Limit the frequency of breaking changes
Release non-breaking changes more frequently

What is a breaking change?
Google has a good guide for their API that we could use. What's our version?
Backwards-compatible (non-breaking) changes

Adding a new optional input
Adding a new output
Changing an internal implementation without changing existing external functionality

Backwards-incompatible (breaking) changes

Adding a new required input
Changing the value of an output
Changing an optional input to required
Removing an input
Removing an output
Adding new external dependencies (like the kubernetes provider)

Stop or Limit the frequency of breaking changes
This module is the Terraform equivalent of an API, but it releases breaking changes as if it were still in beta. Compare it to the VPC module which stayed on 1.X for almost 2 years, and only went to 2.X when it went to Terraform v0.12 support.
Suggestion: Stop accepting breaking changes from public PRs. Instead, set up a regular major version release cadence of X months, and solicit feedback from the community on what breaking changes might be necessary. Then decide what makes it in the next major release, implement the changes (yourself or by soliciting PRs to a feature branch instead of master), create a solid migration guide, create an automated migrator tool if possible
Release non-breaking changes more frequently
One of the principles of DevOps is improving flow by reducing batch size. Make releases as small as possible by releasing non-breaking changes (minor or patch releases) as frequently as possible. If a PR adds a new feature and it is complete, well documented, doesn't have breaking changes, and is generally "ready to go", there's really no reason to not immediately do a release.
Doing very small, very frequent releases provides a number of advantages:

Reduces per-release complexity, which makes people upgrading more confident that they can do so safely and quickly
Get feedback sooner on new features
If a release causes a bug, you can revert the release without lots of collateral damage

* Are all four ways to launch worker nodes actually necessary?

launch_configurations are historical. A lot of people haven't moved their thinking on from these old resources. They were the first ones implemented in the module and removing them would be a big breaking change for many.
launch_templates do a lot more than launch_configurations can.
node_groups are new and don't implement features that people need. But have abstract away some of the life cycle so users want them. Why do they require public IPs? Why don't they inherit custom tags from the node group resource?
fargate. Way more abstraction. Way more cost. People want it.

Currently, yes, we need all 4 😞

* Under what use cases would a user want `manage_aws_auth = false`?

You have to be able to dial in to the cluster in order to manage the aws-auth file. What if you want a fully private cluster? You need to somehow get your Terraform to run on a network that has access to that private endpoint.
In released versions it also meant a call out to kubectl and a shell environment. This was difficult for Windows users. I believe it's also really difficult for users in Terraform Cloud but I haven't tried myself.
Plus long running issues with AWS API returning "READY" before the endpoint was actually ready to receive requests. Maybe someone running a lot of startup and shutdown automated tests gave up and split their creation process in two?

* How often will people use EKS but _not_ want the ability to assign IAM roles to pods, which is what IRSA allows?

Anything to do with IAM is always a tricky issue. Some corporate environments run with very restrictive policies and CI or devs do not have the ability to create IAM roles or policies. Creation of IAM resources is on a toggle because users have requested it. Creation of the OIDC provider needs to be optional for the same reason.

I've noticed a significant build up of non-breaking changes and new features under [v8.?.?] - 2019-??-??] in the changelog. IMO we should strive to release these as part of a minor increment

Releases need to be more frequent. I think we can all agree on that.

Turning node groups into a submodule is a great example of this: You still have all the code that would otherwise be in node_groups.tf, plus duplicate code for outputs.tf and variables.tf, plus the extra code for calling the submodule itself

I'm happy to sacrifice DRY for simplicity in this case. For example, managed node groups (MNGs) are getting a lot of attention now but all the code is mixed up with all the logic/maps/merging/defaults/IAM/etc of the normal worker group stuff. If we can move it to a submodule, then we can merge 10 PRs related to MNGs without worrying about impacting the core of the module. And same for the coming fargate stuff.

Yes 100%

Under what use cases would a user want manage_aws_auth = false?

When a user has another tool for managing k8s resources. Like Helm, Kustomize, etc

Release non-breaking changes more frequently

Yes, 100% agree.

Compare it to the VPC module which stayed on 1.X for almost 2 years, and only went to 2.X when it went to Terraform v0.12 support.

It's optimistic to compare the complexity of these 2 modules and speed of innovation in their respective areas but in principle I agree with you for sure.

Suggestion: Stop accepting breaking changes from public PRs

I think this will be hard given the current rate of change in the k8s/EKS area?

My 2cents as a user of the module.
First off in terms of breaking changes. I am not overly worried about changes to your API, the surface area isn’t huge and if they are well documented and communicated its fine.
However I do care a lot about things like:

When I make a small change and perform a plan does the diff make sense, or is it full of surprises?
When I do a successful plan and then an apply does it work or can it fail with (for example https://github.com/terraform-aws-modules/terraform-aws-eks/issues/635)?
Do small changes trigger it to start tearing down the cluster?

Right now my experience using the module isn't great in terms of the aspects I just listed. I am new to terraform though so I’m not clear if the problems we're experience are caused by this module, or its interaction with other modules we’re using, or if my issues primarily stem from Terraform itself. Maybe a bit of all of them.
So this brings me onto potential solutions. In terms of breaking the codebase up, as a user I don't have a strong view as long as there is an upgrade path. However I am pretty worried about the talk of a lack of automated testing. I don't see how you can maintain a complex module without good automated tests, but I think trying to restructure without regression test suite would be very difficult. I thus think improving testing might be a useful first step.
Also I am surprised at the talk of dropping Windows support. As (currently) a Windows user that seems like it might be a mistake, I realise I could run the module in a container but that definitely adds friction.

https://github.com/terraform-aws-modules/terraform-aws-eks/issues/476#issuecomment-540177369

i agree on several points:

thanks and appreciation for this community-driven module
better documentation for breaking changes
splitting into smaller modules
due to some of what i described in https://github.com/terraform-aws-modules/terraform-aws-eks/issues/476, i ended up forking this module and then splitting into our own eks-control-plane and eks-worker-groups modules.  after using them for a few months, i can say i prefer being able to control the two parts of the cluster independently (aka diff tf states).  the plan was to keep up-to-date with this module as much as possible so i could pick up changes i want like using the kube provider, but it's hard when there is so much packed in (especially stuff i'm really not interested in).
in any case, this module has been incredibly valuable to our team and let me know if i can help somehow.  i still gotta find time to get our two modules into a state that i can share

i agree on several points:
-thanks and appreciation for this community-driven module
-better documentation for breaking changes
-splitting into smaller modules

due to some of what i described in #476, i ended up forking this module and then splitting into our own eks-control-plane and eks-worker-groups modules. after using them for a few months, i can say i prefer being able to control the two parts of the cluster independently (aka diff tf states). the plan was to keep up-to-date with this module as much as possible so i could pick up changes i want like using the kube provider, but it's hard when there is so much packed in (especially stuff i'm really not interested in).
in any case, this module has been incredibly valuable to our team.  i gotta find time to get our two modules into a state that i can share.

@aeugenio
Do you see your module as being a project that will be maintained going forward?

Reopening this issue. We're still far away from the target.

I haven't read all the comments yet but I agree with the core sentiment @max-rocket-internet . It's a part of why I've largely walked away from the project - there needs to be hard bounds around keeping modules simple, to the point, and guided by a design north star. In reality, that means saying no to a lot of feature requests and issues but that leaves people upset. It's a lose-lose proposition from a maintainer's point of view and eventually the consumers of the module suffer just the same. I've got no good answers here - this module is wildly successful but also a monstrosity.

A few thoughts as a (very) minor contributor with an interest in the future of this module:

With the release of Launch Template support for Managed Node Groups, it's reasonable IMO to drop support for self-managed worker ASGs and support exclusively MNGs (with eventual support for Fargate). That should massively decrease the complexity of the module since it no longer has to have all sorts of conditionals around which type of workers are in use.
Leveraging 0.13's new features around modules should help to further reduce complexity. For example, creating a module for Managed Node Groups and then looping over that is nice and clean vs. what exists today
Splitting this module into a handful of submodules should increase testability, which I think is vitally important for a module of this nature. For example, moving the parts of the module that deal with security groups into their own submodule would allow those behaviours to be tested without requiring spinning up an entire cluster. Obviously there should be some consideration to not stumble into the "thin wrappers" problem that @brandonjbjelland mentioned, but my gut feeling here is that this module needs a lot more testing and that it's going to be difficult-to-impossible to improve that given the current monolithic nature.

With the release of Launch Template support for Managed Node Groups, it's reasonable IMO to drop support for self-managed worker ASGs and support exclusively MNGs (with eventual support for Fargate).

yeah, nah.... MNG's are terrible and limited.

Thanks guys for all your work. As a consumer of this module I can say that I'll work through whatever path you guys decide. My clusters are completely disposable (thanks largely to your efforts) and I'll just spin up new clusters, migrate workloads and terminate my old ones regardless of how you want to proceed. As a side note, I upgraded to Terraform 0.13, pulled master yesterday and spun up a new sandbox cluster no changes to anything but local code.

With the release of Launch Template support for Managed Node Groups, it's reasonable IMO to drop support for self-managed worker ASGs and support exclusively MNGs (with eventual support for Fargate).

yeah, nah.... MNG's are terrible and limited.

Agreed. I just ran into the very awkward issue that you can't attach existing security groups onto worker nodes. The remote_access block only allows you to specify ingress security groups, but you can't attach any arbitrary security group to the worker nodes.
The only way around this is to use the new launch_template block. But if I have to create the whole launch template (including the ami, user_data block, and everything else) then it's not very "managed" at that point.

@max-rocket-internet @antonbabenko @barryib @dpiddockcmp I just opened https://github.com/terraform-aws-modules/terraform-aws-eks/issues/1031, and now I'm wondering what the decision was on this?
Perhaps we should have a virtual meet to discuss this? I don't mind splitting this into more than one module, and even happy to do the initial work since I have to do it for my work anyway.
Are we going the route of splitting the modules like so?
cloudposse/terraform-aws-eks-workers will provision an ASG with EC2 nodes
cloudposse/terraform-aws-eks-node-group provisions a managed node pool
cloudposse/terraform-aws-eks-fargate-profile adds fargate support```

@sc250024 yep. We've already got node-groups and fargate submodules.
There is an ongoing PR https://github.com/terraform-aws-modules/terraform-aws-eks/pull/858 for worker groups which will introduce a huge breaking change.
Also there is a terraform-aws-module office hour on November 6th, 15-16:00 CET (9-10am, EST) See https://github.com/orgs/terraform-aws-modules/teams/triage-supporters/discussions/8. We can probably discuss there if there is time left.

I feel like big modules like this one here would benefit from being implemented with something like Pulumi (once it fully matures)

I feel like big modules like this one here would benefit from being implemented with something like Pulumi (once it fully matures)


children is not assignable to

My Next.js Version : 12.1.6

You can declare this in a .d.ts file :
declare module 'next-translate-routes/link' {
  export declare const Link: React.FC<React.PropsWithChildren<LinkProps>>;
  export default Link;
}

Or downgrade your project to React 17


fix the new transliteration file

fixed the new transliteration file
rename old transliteration file for reference

old transliteration has underscore, dash and bold. Are you sure you want to replace it with new one?
old demo:
http://globalquran.com/en.transliteration+quran-uthmani/1:1

Also, if you are sure you want to replace above with new simple text transliteration, then please add meta data info from previous file. it is missing meta data info after 6236 lines.

@iBasit I prefer the new transliteration they are more in line with how you would pronounce it (tajweed) i.e Bismillaahir, but we could have both and let the user decide.

ok sure, please fix meta data. bump it.

@iBasit that's done

Sorry, but you need to remove old file or remove its meta data..  it will conflict between them.

@iBasit what should I rename it to.

I have edited my comment

@iBasit ok, I have removed the metadata.


fix: mongodb atlas delete function to delete all ref doc from vector …

…store
See https://github.com/run-llama/LlamaIndexTS/issues/871

already merged


⚠ gorzdrav.org has degraded performance

In d92c663, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 2351 ms

Resolved: gorzdrav.org performance has improved in 27d674e.


Formatting of the log strings

Hi! I cannot find any info about the format of the log strings. Currently, it gives me too much useless info. Is there any possibility to change the format?

Which logs? flynn-host logs or app logs?

flynn-host logs

What do you think is useless?

From DigitalOcean droplets I receive logs like this Aug 16 17:21:52 flynn-production-ams2-node-1 4585242b-9685-4619-ac58-93c2472f9801.log:  244 <0>1 2017-08-16T15:21:52.785788344Z flynnproductionams2node1 4585242b-9685-4619-ac58-93c2472f9801 worker.flynnproductionams2node1-bf5c60f0-ddf7-40e6-98cd-6b9a3744d52c ID2 [flynn seq="1850673"] cannot send spans: [Errno 110] Connection timed out, where the middle part is not interesting for me 244 <0>1 2017-08-16T15:21:52.785788344Z flynnproductionams2node1 4585242b-9685-4619-ac58-93c2472f9801 worker.flynnproductionams2node1-bf5c60f0-ddf7-40e6-98cd-6b9a3744d52c ID2 [flynn seq="1850673"].
Can I edit somehow the format to not display this?

The metadata is used internally, so it can't be removed. You can add a syslog log sink with flynn cluster log-sink.

ok, thank you.


Add guide for downloading datasets and configure the path

Datasets

ai challenger dataset
coco 2017 dataset

hello did you get to know-how downloading  and configure datasets path

@raouf2004
Sure.
1. Download Dataset
In recent PR, we support to download coco dataset 2017 with python script. So you can download the coco dataset with the following command.
python downloader.py --download-path={DATASET_PATH}
# python downloader.py --download-path=/home/dataset/coco2017

2. Change Dataset Path On train.py
And then configure the dataset_path with your above {DATASET_PATH}
https://github.com/tucan9389/tf2-mobile-pose-estimation/blob/05d1e88cd0fe32606d6c094b4534d55cf17a0aa4/train.py#L42

Or, if you want to download coco 2017 dataset manually, please check the link.


yapi不支持node10.x.x

版本号
<EMAIL_ADDRESS>什么问题
(node:27797) UnhandledPromiseRejectionWarning: Error: getaddrinfo ENOTFOUND yapi.demo.qunar.com yapi.demo.qunar.com:80
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)
(node:27797) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:27797) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
当前安装版本： 1.9.1
连接数据库成功!
开始下载平台文件压缩包...
http://registry.npm.taobao.org/yapi-vendor/download/yapi-vendor-1.9.1.tgz
部署文件完成，正在安装依赖库...
npm
WARN npm npm does not support Node.js v10.15.2
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN
npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9.
npm WARN
npm You can find the latest version at https://nodejs.org/
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
up to date in 1.197s
依赖库安装完成，正在初始化数据库mongodb...
Error:  npm
如何复现此问题
正常安装，执行yapi server 后，进行部署
什么浏览器
chrome
什么系统（Linux, Windows, macOS）
linux

楼主，请问解决了吗，
遇到了一样的报错


tour: improving the example by adding two more output

Context: https://go.dev/tour/moretypes/6
package main

import "fmt"

func main() {
	var a [2]string
	a[0] = "Hello"
	a[1] = "World"
	fmt.Println(a[0], a[1])
	fmt.Println(a)

	primes := [6]int{2, 3, 5, 7, 11, 13}  // [2 3 5 7 11 13]
	fmt.Println(primes)

	second := [10]int{2, 3, 5, 7, 11, 13}	// output: [2 3 5 7 11 13 0 0 0 0]
	fmt.Println(second)

	// third := [5]int{2, 3, 5, 7, 11, 13}  // Error Exception: index 5 is out of bounds (>= 5)
	// fmt.Println(third)
}

The tour does not seem to explicitly cover that "the zero value of an array is a ready-to-use array whose elements are themselves zeroed".  If you were to make the changes above I think you should update the slide text as well to talk about array zero values.


KeyValues not reloaded with mod menu

Changing enabled/disabled mods and leaving the mod menu/running Reload Mods does not recompile KeyValue files.
A bit of a hacky solution would be to set a cvar to true on reload, and have the server run weapon_reparse if so. Not sure if issues can arise from trying to do so too early, though.

#324 should fix this


Generating cf manifest file fails using generate_development_manifest on AWS

I followed the link  to create  cf manifest file. I have cloned

cf-release

from git on my linux system and created cf-stub.yml file as below
---
director_uuid: 5f60d6bd-3775-4f6d-a6b8-52ed6b5c5249
properties:
  domain: bosh-lite.com

Then executed file "generate_development_manifest'.
[ec2-user@ip-10-0-1-234 cf-release]$ ./scripts/generate_deployment_manifest aws cf-stub.yml > cf-deployment.yml
It gave an error as below
error generating manifest: unresolved nodes:
        (( merge ))     in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      networks        (networks)
        (( merge ))     in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      properties.template_only        (properties.template_only)
        (( static_ips(1) ))     in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[0].networks.[0].static_ips        ()
        (( static_ips(1) ))     in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[1].networks.[0].static_ips        ()
        (( static_ips(5, 6, 15, 16, 17, 18, 19, 20) ))  in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[2].networks.[0].static_ips        ()
        (( static_ips(5, 6, 15, 16, 17, 18, 19, 20) ))  in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[3].networks.[0].static_ips        ()
        (( static_ips(27, 28, 29) ))    in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[10].networks.[0].static_ips       ()
        (( static_ips(27, 28, 29) ))    in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[11].networks.[0].static_ips       ()
        (( static_ips(10, 25) ))        in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[12].networks.[0].static_ips       ()
        (( static_ips(9) ))     in /home/ec2-user/workspace/cf-release/templates/cf-infrastructure-aws.yml      jobs.[13].networks.[0].static_ips       ()

after looking deep in it come to know that it merges three files
cf-infrastructure-aws.yml
cf.yml
generic-manifest-mask.yml

why this error comes ?
How to fix ?

Any solutions or suggestions?

@Niranjana-5588 the folks watch the cf-release repo would be better equipped to answer manifest generation questions. You could also ask at cloudfoundry.slack.com in the #release-integration channel.

I don't belongs to cloudfoundry.slack.com team. Please add me to this team. It will be helpful to post this issue in #release-integration channel.

@Niranjana-5588 You can sign up here: https://slack.cloudfoundry.org/

Hi @Niranjana-5588 . It looks like your stub is incomplete -- for example, you're missing a section in your stub for networks. The best place to start is with these docs on creating a stub for AWS. If you have any further issues or questions, please open a github issue on cf-release.
@ljfranklin, feel free to close this issue.

Apparently I can't close issues in this repo, pinging @tylerschultz or @cppforlife to close.


Matching by _id isn't working

I'm not sure if this is me but for some reason aggregate matching by _id isn't working.
I saw this issue:
https://github.com/meteorhacks/meteor-aggregate/issues/6
and am using the following code but it isn't working? Thoughts?
      let res = collection.aggregate([
        {$match: {'_id': new Mongo.ObjectID('bea1bce7e3276818dd06a34f')}}
      ]);
      console.log(res);

I observe the same thing with collection return by Meteor Mongo.Collection#rawCollection method.

I observe the same thing with aggregate method of collection returned by Meteor Mongo.Collection#rawCollection

you might check this comment.


.exe is not working

The Extreme Injector v3.exe is not opening, any solutions?
I want something simple to be able to make screenshots, but I dont want to use cheat engine >_<

https://github.com/FransBouma/InjectableGenericCameraSystem/tree/master/Tools/IGCSInjector


Compatibility with typescript 5.6

Bug report

What is the current behavior?
.yarn/__virtual__/webpack-virtual-5df32c374e/3/AppData/Local/Yarn/Berry/cache/webpack-npm-5.94.0-d1e43de389-10c0.zip/node_modules/webpack/types.d.ts:13611:2 - error TS2416: Property '[Symbol.iterator]' in type 'SortableSet<T>' is not assignable to the same property in base type 'Set<T>'.
  Type '() => IterableIterator<T>' is not assignable to type '() => SetIterator<T>'.
    Type 'IterableIterator<T>' is missing the following properties from type 'SetIterator<T>': map, filter, take, drop, and 9 more.

13611  [Symbol.iterator](): IterableIterator<T>;

If the current behavior is a bug, please provide the steps to reproduce.
Run tsc on a webpack project with skipLibCheck: false
What is the expected behavior?
No errors
Other relevant information:
webpack version:  5.94.0
typescript version: 5.6.2

Also seeing this error when using skipLibCheck: false
Note: I initially had more Webpack errors, but they were solved by upgrading @types/node to the latest 22.5.4. But this specific error remains after the upgrade.


Most common entity extraction issues

We're trying to collect a list of the most common issues people have with entity extraction. What we have so far:

Please vote for the ones you also have issues with, or comment with any other common issues you have 🙂

Names matching rwgex

@kumarv1988 could you elaborate on what "names matching regex" are?

Looking forward to phrase_matcher merger!

@akelad what about entity roles? e.g. origin_location,  destination_location ?

@AbdurRub what does phrase_matcher do?

regex for person names? e.g. First_name, last_name?

https://github.com/RasaHQ/rasa_nlu/pull/822  @venky14

The entity recognition is not good for custom locations : for instance when i model it for hospitality industry, each hotel may have many restauraants within, other places for us all of them are treated as a place within hotel : restaurants, spas, gyms, reception, hotel shop etc. the entity recognition is not accurate always in this case.
Also, often the model takes the stop words as entities : eg: user utterance: "Where is the sea food restaurant ? " the model takes "the seafood restaurant". at present I am cleaning up it with python .
(these are few that I noted, but I could list many ;)

@akelad  not able to extract a custom regex based alphanumeric entity with regex  pattern like
(?i)(SR)[0-9]* in rasa nlu

Are there any news on whether Entity roles will be supported or not?


[Breaking Changes] allow setup on machine which zsh isn't pre-installed, and drop linux support

If you don't pre-install zsh, you can setup.
Because I don't have linux machine and I haven't use this dotfiles on real linux machine, I drop linux support for maintainability.

==> Purging files for version 112.0.5615.49 of Cask google-chrome
Error: It seems there is already an App at '/Applications/Google Chrome.app'.
Installing google-chrome has failed!

<internal:/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- psych (LoadError)
	from <internal:/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems.rb:608:in `load_yaml'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/config_file.rb:346:in `load_file'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/config_file.rb:189:in `initialize'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems.rb:329:in `new'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems.rb:329:in `configuration'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/user_interaction.rb:167:in `verbose'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/installer.rb:544:in `generate_bin_script'
	from ./tool/rbinstall.rb:891:in `generate_bin_script'
	from ./tool/rbinstall.rb:855:in `generate_bin_script'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/installer.rb:506:in `block in generate_bin'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/installer.rb:490:in `each'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/installer.rb:490:in `generate_bin'
	from /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj/ruby-3.2.2/lib/rubygems/installer.rb:331:in `install'
	from ./tool/rbinstall.rb:881:in `block in install'
	from ./tool/rbinstall.rb:721:in `no_write'
	from ./tool/rbinstall.rb:881:in `install'
	from ./tool/rbinstall.rb:989:in `block in install_default_gem'
	from ./tool/rbinstall.rb:976:in `each'
	from ./tool/rbinstall.rb:976:in `install_default_gem'
	from ./tool/rbinstall.rb:913:in `block in <main>'
	from ./tool/rbinstall.rb:1080:in `block in <main>'
	from ./tool/rbinstall.rb:1077:in `each'
	from ./tool/rbinstall.rb:1077:in `<main>'
make: *** [do-install-nodoc] Error 1

BUILD FAILED (macOS 12.6.4 using ruby-build 20230330)

Inspect or clean up the working tree at /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.32v1Yj
Results logged to /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/ruby-build.20230413002041.48429.log

Last 10 log lines:
	from ./tool/rbinstall.rb:721:in `no_write'
	from ./tool/rbinstall.rb:881:in `install'
	from ./tool/rbinstall.rb:989:in `block in install_default_gem'
	from ./tool/rbinstall.rb:976:in `each'
	from ./tool/rbinstall.rb:976:in `install_default_gem'
	from ./tool/rbinstall.rb:913:in `block in <main>'
	from ./tool/rbinstall.rb:1080:in `block in <main>'
	from ./tool/rbinstall.rb:1077:in `each'
	from ./tool/rbinstall.rb:1077:in `<main>'
make: *** [do-install-nodoc] Error 1

Your flutter checkout has local changes that would be erased by upgrading. If you want to keep these changes, it is recommended that you stash them via "git stash" or else commit the changes to a local branch.


HADOOP-18198. Add release 3.3.2 diff files

Adds the 3.3.2 jdiff files which were left out of the
release commit...the ones the release doc didn't mention.
This is needed for the 3.3.3 build to complete.
How was this patch tested?
this is a working branch to sync between my dev machine and the machine running create-release;
testing in progress.
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
3m 53s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

_ branch-3.3.3 Compile Tests _

+0 :ok:
mvndep
5m 40s

Maven dependency ordering for branch

+1 :green_heart:
shadedclient
33m 14s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s

Maven dependency ordering for patch

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 3012 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-1 :x:
blanks
0m  1s
/blanks-tabs.txt
The patch 5 line(s) with tabs.

+1 :green_heart:
xml
0m 12s

The patch has no ill-formed XML file.

+1 :green_heart:
shadedclient
22m 22s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
asflicense
0m 40s

The patch does not generate ASF License warnings.

62m 46s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4202/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4202

Optional Tests
dupname asflicense codespell xml

uname
Linux e1f8632924c2 4.15.0-175-generic #184-Ubuntu SMP Thu Mar 24 17:48:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.3.3 / e8ed69fe3d3dda7ece9907ed62c41c8f5fc045c2

Max. process+thread count
543 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn hadoop-common-project/hadoop-common hadoop-mapreduce-project U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4202/1/console

versions
git=2.17.1 maven=3.6.0

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 42s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

_ branch-3.3.3 Compile Tests _

+0 :ok:
mvndep
8m 16s

Maven dependency ordering for branch

+1 :green_heart:
shadedclient
33m 20s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s

Maven dependency ordering for patch

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 3012 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-1 :x:
blanks
0m  0s
/blanks-tabs.txt
The patch 5 line(s) with tabs.

+1 :green_heart:
xml
0m 14s

The patch has no ill-formed XML file.

+1 :green_heart:
shadedclient
22m 33s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
asflicense
0m 35s

The patch does not generate ASF License warnings.

59m 50s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4202/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4202

Optional Tests
dupname asflicense codespell xml

uname
Linux c2dd4c7f2292 4.15.0-175-generic #184-Ubuntu SMP Thu Mar 24 17:48:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.3.3 / 063c1196599e6a0992aa26fa7bd36096c18910f0

Max. process+thread count
557 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-yarn-project/hadoop-yarn hadoop-mapreduce-project U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4202/2/console

versions
git=2.17.1 maven=3.6.0

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

merged this into the 3.3.3 branch; will do the same for the other branches if it is working there


nydusd: fixed getting the wrong chunk due to using the wrong blob index

The blob index on the disk where erofs exists starts at 1, but the blob index in BlobInfo starts at 0,
and the blob index on the disk is mistakenly used here instead of blobInfo's index
this will eventually result in the wrong file contents being obtained.
Signed-off-by: zyfjeff<EMAIL_ADDRESS>

@zyfjeff , a new test job has been submitted. Please wait in patience.

could you leave some words on what it will impact?

You're right, I'll change it.

Why does this patch relate to nydus-image? It looks like a change of nydusd runtime

You're right, I'll change it.

@zyfjeff , your pull request has been updated. A new test job will be submitted. Please wait in patience.

@zyfjeff , your test job has passed, and no need to test again.

could you leave some words on what it will impact? it impact chunk info?

This will cause the contents of the file to be confused, or the chunk index to go out of bounds

I don't quite understand why data is corrupted. I think it can only cause wrongly generating descs which is a set of backend chunk IO, which means backend IO merging is low-efficient.

I don't quite understand why data is corrupted. I think it can only cause wrongly generating descs which is a set of backend chunk IO, which means backend IO merging is low-efficient.

This will result in a BlobIoVec containing different Blobs, but where BlobIoVec is used, it is assumed that they all belong to the same Blob, but it is not, which will result in chunks being taken from the wrong blob


add docs for double dash and new babel-external-helpers options

Formats section was more detailed but I have decided to shorten it to minimum since everybody can simply type it into console and check the output. Sorry that it took so long.

Thanks!


Workflow Issue

I can understand the author's effort to complete this task in a short time, but it seems that the description of the workflow in the Readme is not complete, which resulted in some time being wasted during debugging.

To assist you and other users better, could you please provide more details.


Prevent interaction with form elements in PresentationMode (issue 12232)

Prevent mouse interaction with form elements in PresentationMode (issue 12232)

Prevent keyboard interaction with form elements in PresentationMode (issue 12232)
This uses the relatively new HTMLElement.inert property, see https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/inert for additional information. The only "problem" is that this isn't yet available in all Firefox channels, but until https://bugzilla.mozilla.org/show_bug.cgi?id=1764263 is fixed we're no worse off than before.

/botio-linux preview

/botio test


turtlebot3 bringup incomplete tf

Which TurtleBot3 you have?

[ ] Burger
[x] Waffle
[ ] Waffle Pi

Which SBC(Single Board Computer) is working on TurtleBot3?

[ ] Raspberry Pi 3
[x] Intel Joule 570x
[ ] etc (PLEASE, WRITE DOWN YOUR SBC HERE)

Which OS you installed in SBC?

[x] Ubuntu MATE 16.04 or later
[ ] Raspbian
[ ] etc (PLEASE, WRITE DOWN YOUR OS)

Which OS you installed in Remote PC?

[x] Ubuntu 16.04 LTS (Xenial Xerus)
[ ] Ubuntu 18.04 LTS (Bionic Beaver)
[ ] Linux Mint 18.x
[ ] etc (PLEASE, WRITE DOWN YOUR OS)

Write down the commands you used in order
[Remote PC] roscore
[SBC] roslaunch turtlebot3_bringup turtlebot3_robot.launch
[Remote PC] rqt

Please, describe detailedly what difficulty you are in

Hi,
I'm relatively new to ROS and the turtlebot.
When I try to bringup the turtlebot, there is no error message, but the tf tree seems to be incomplete.
The only transformations broadcasted are odom -> base_footprint and base_link -> imu_link.
So when I start rviz for example it misses some parts of tf (eg for the laser scanner).
How can I bring up the remaining transformations? Where are they called from? As far as I can tell, in the Arduino file, only the above mentioned transformations are broadcasted.
Thanks in advance!

Hi @tedalias,
When you run the launch file below on your Remote PC, you will get information about the robot model. You will then be able to see all of the tf information you want.
roslaunch turtlebot3_bringup turtlebot3_remote.launch

https://github.com/ROBOTIS-GIT/turtlebot3/blob/master/turtlebot3_bringup/launch/turtlebot3_remote.launch
Please refer to the following manual for more details on bringup.
http://emanual.robotis.com/docs/en/platform/turtlebot3/bringup/#bringup-a-turtlebot3-burger

Thanks, @robotpilot , that was the part I was missing. It works now.
Closing the issue


fix: prevent partial payout underflow

Bump codex-contracts-eth to prevent an underflow from occurring when calculating partial payout amounts during fillSlot.

catch 404 in CodexClient.getPurchase and return a failure instead of letting the exception bubble

These changes are also used in a larger PR (https://github.com/codex-storage/nim-codex/pull/607) and are being introduced to break up the PR.


It's a bit laggy.

If it would send, receive, and show read faster that would be great. And if it showed the typing bubble that'd be way cool too. Other than that, it's great I love it.

What version of IGdm are you using? The latest version is pretty fast

On 8 Feb 2019, at 2:19 AM, 2AroBaticCats<EMAIL_ADDRESS>wrote:
If it would send, receive, and show read faster that would be great. And if it showed the typing bubble that'd be way cool too. Other than that, it's great I love it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

The latest, 2.6. I'm using windows so idk if that changes anything.


Add hints extension to docs

The extension got moved to dry-schema but it is still needed in
dry-validation to enable hints for contracts.

Thank you 🙂

Hey @solnic ! I am wondering why the new documentation doesn't appear on the main site?
https://dry-rb.org/gems/dry-validation/main/extensions/|
Is there a job to be ran or something wrong with how I added it?

@bautrey37 the deployment action that we used was broken, so I just switched to another one that works and your addition is now visible on the site https://dry-rb.org/gems/dry-validation/main/extensions/#hints thanks!


fix(edit-kpi): issue #965 of dashboard getting reset to All after editing a KPI.

Fixes Issue #965

Tested - editing aggregation (works, dashboards not affected), editing dashboards (works, nothing else affected).


saving of configuration

We need to able to save current configuration to a local file , usb or network storage iscsi?
an then recover this configuration for use in another setting.

good point, and this is already implemented in the newest version to be made available soon.

@haniavis I assigned you just to be sure that this is correct since I didn't try it myself yet. But also to play a little with the github features :-)

Actually, I am confused because I thought that this is for the "portal" while this is the "mazi-board" issues. Would you like to have the same feature (saving configuration) for the mazi-board as well?

I am re-opening this since it is not clear if it refers to the portal or the mazi-board aka guestbook.

we need to be able to save all the configurations for all the apps installed and the overall interface. I think we should go further and encourage sharing of configurations.. not least as start points for others to test out if they can't imagine what can be done.

I agree with James - it would be good to be able to easily share alternative configurations between communities using mazizones. At this stage, I would be interested as part of the CreekNet team to be able to try out the mazizone configurations being used in different pilots to see if we can learn from their approaches. #

I am adding this here again as the earlier notes vanished. Regards import and export of toolbox configuration, we were able to setup our installation and export from the admin interface and then save that config to an local/external storage, great. However it did not record the appearance settings which has a separate option to save a 'theme' but does not offer export in the same way as the rest of the config, so is not portable.

Hi, I think this is meant to be the same issue as this one #6, which is already answered ...

oh hell yes.. so it is

You can now export the configuration of the Guestbook application (message, background image, tags etc.), together with its content (posts, photos, comments etc.), using the "Application Snapshots" section in the Export/Import menu.


Asking for help

Dear @Blaukovitch ,
What am I missing in this to make it work without VxKex? I have no useful skills with x96Debug.
(vivaldi.exe and vivaldi.dll has few breakpoints.)
https://github.com/adeii/supermium-portable/releases/tag/v6.9

it work without VxKex?

Hello!
But you have problems, if vivaldi start WITH VxKex?

Yes, when using another PC with Win 8.

What is kind of problem? Browser not start or any errors shows?

Remain in background, as running process but no windows nor frame at all. Not even an error pop-up.


Sbt 1.3.0-RC2

I counted (roughly) 38/60 jobs either failed or errored 🙁  Hopefully it's for a small number of reasons (e.g. 1).
[error] Test controllers.HomeControllerTest.testWebsocket failed: java.lang.NoClassDefFoundError: io/netty/channel/unix/UnixChannelOption, took 0.466 sec
[error]     at play.core.server.NettyServer.initializeChannelOptionsStaticMembers(NettyServer.scala:314)
[error]     at play.core.server.NettyServer.<init>(NettyServer.scala:63)

[error] Test ModelTest.pagination failed: org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda expression in ModelTest that uses java.util.concurrent.CompletionStage
[error] Expecting:
[error]   <io.ebeaninternal.server.query.LimitOffsetPagedList@1e7b68d2>
[error] to match given predicate.

[error] (update) sbt.librarymanagement.ResolveException: Error downloading org.webjars.npm:dom-serializer:[0,1)
[error]   Not found
[error]   not found: https://repo1.maven.org/maven2/org/webjars/npm/dom-serializer/%5B0,1)/dom-serializer-%5B0,1).pom
[error]   not found: /home/travis/.ivy2/local/org.webjars.npm/dom-serializer/[0,1)/ivys/ivy.xml
[error]   download error: Caught java.net.URISyntaxException: Illegal character in path at index 87: https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/org.webjars.npm/dom-serializer/[0,1)/ivys/ivy.xml (Illegal character in path at index 87: https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/org.webjars.npm/dom-serializer/[0,1)/ivys/ivy.xml) while downloading https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/org.webjars.npm/dom-serializer/[0,1)/ivys/ivy.xml

cc @eed3si9n

Reported the problems upstream in sbt/sbt's 1.3.0 milestone.  Closing this, we'll try upgrading again next time.


Generate and auto-fill (with IYO info) documents for use in IYO.SEE

We will need a way to generate and auto-fill (with IYO info) documents for use in IYO.SEE
For example, hosters' contracts https://docs.google.com/document/d/1NRbsXyb705N-VLMP4jC9aYHOZ3eGYmVjvXkmHd3nmn4/edit contain references to hosters names, address, current date and so on.
For IYO.SEE, "signed" copies of such documents should be auto-filled with information known to IYO.
Basically, TF docs to be processed in IYO.SEE have to contain assignable variables in order to generate personalised docs.

first show a message with a summary of the collected IYO data. Add a button to change this info. And a button to accept and continue.


Define header to identify our own requests

Fixes #154.

@ofrobots PTAL. Tests relying on this constant still pass because undefined is a valid object key in javascript :trollface:

lgtm w/ comment.


Added referrer policy header (using helmet) to server sub-generator

 Add referer policy using Helmet

Coverage decreased (-1.7%) to 98.316% when pulling 676dc3e360e075296713618402527cbd3015270f on feature/helmet-referrer-policy into 9b2921bfe28b15da92eae58c5932eb0885caaa6c on master.


Introduce Option to omit VolumeBackup container option

When using Ceph RBD Backup driver, the container attr set when creating a VolumeSnapshot has to either correspond to the backup rbd pool or be omitted. Many users might not know which rbd_pool that is, so it should just be omitted in that case. Similar to #107
Since most OS clouds use ceph, it might even make sense to omit it by default and let the user have to explicitly set it. Any thoughts?

Hello, thank you for PR.
I will need some days to get to this due to business trips. Thank you for patience.

Hello @modzilla99,
I apologize. I completely forgot about this PR. Let me recheck this.

The idea makes sense to me.

@modzilla99
The MR still has WIP title. Let me know when you are finished and remove the WIP from title please.

Hi, there are conflicts in the PR. Can you please fix them?
Also you can use comment to let me know when it's fixed so that I'm notified. It will be faster to merge this PR.


fix(ServiceStatusProgressBar): fix progress bar

Fix progress bar where it shows fully complete when still deploying.
This commit also improve the logic to always display the tooltip and use less code
for the progress bar.
Closes DCOS-19731
Scaling/deploying already running service

Deploying

Deleting

Checklist

[x] Did you add a JIRA issue in a commit message or as part of the branch name?
[ ] Did you add new unit tests?
[ ] Did you add new integration tests?
[ ] If this is a regression, did you write a test to catch this in the future?

Some tasks take the whole village :D


Update Lace browser extension version: v1.10

Checklist

[x] JIRA - LW-10198
[ ] Proper tests implemented
[ ] Screenshots added.

Update Lace browser extension version for the release v1.10

coverage: 50.56%. remained the same
when pulling 0c0f3ed954c02e50c077aa09f913fe4a54feae03 on chore/update-lace-version
into 1045749eb5c738b890cac0b09857332894f0d118 on main.


We need documentation for Project Structure

Project Directory will help beginners to understand the code.
Project Structure must be saved in root location with name projectStructure.md
This structure must describe each and every folders or file and their role in the project.

It is now assigned to @ktavleen , but if anyone also interested can also contribute and send the PR to master branch for this.

@imabp , I'd like to help. Is there an example of what the file should look like?

@TomerPacific happy to see that.
@ktavleen @TomerPacific you both can divide the work as project structure is vast. Assigning this to you both.
This is bit lengthy task and also requires proper project folders understanding.  All the best both of you.  @TomerPacific @ktavleen
For example, this is current structure

So if I want to document the structure, it should be like.
src
src contains the main source code for the react-app
src/assets/
Assets contain all the community brand assets in .svg format
src/components/
Components used in this website
src/components/footer
Contains footer component
src/data/
Code implementation for communication with Airtable servers.
src/data/hooks
All web hooks used in the website are listed here.

@imabp , I have opened a PR not because I am finished with the task, but to show you what I am intending to do with it and to ask if this is what you were expecting for it. Please give me feedback if this is what you were looking for (or not).

Fine @TomerPacific We have merged it to development branch. You can start working on it. As this would help other assignee to get started.

@TomerPacific I have changed the directory of the projectStructure to root . Do update your fork.

@imabp , I did not want you to merge my PR, but to give me feedback so I could understand if what I did was what you wanted. I'll continue my work on another feature branch.

@imabp , I have created another PR, but in draft status, so you can comment on the progress so far and if any changes are necessary.

Great you are going right.
Loved the documentation


Review inconsistent field attributes for fields of the same name

A review of the field metadata in src/pudl/package_data/meta/datapkg/datapackage.json reveals the following inconsistencies in constraints.enum and description for fields of the same name across different resources.
Does additional field metadata exist elsewhere than src/pudl/package_data/meta/datapkg/datapackage.json?
Our task is to choose one standard attribute value where possible, rename the field in some resources as needed, and determine whether field metadata can be universal or needs to be customizable by resource (e.g. service_territory_eia861, respondent_id_ferc714).
Fields are removed from the tables below as they are resolved:

field
constraints.enum
resources

state
AL, AR, AZ, CA, CO, CT, DC, DE, FL, GA, IA, ID, IL, IN, KS, KY, LA, MA, MD, ME, MI, MN, MO, MS, MT, NC, ND, NE, NH, NJ, NM, NV, NY, OH, OK, OR, PA, RI, SC, SD, TN, TX, UT, VA, VT, WA, WI, WV, WY
hourly_emissions_epacems

AUS, COL, CAN, IDN, POL, RUS, GBR, VEN, other_country, unknown, AK, AL, AR, AS, AZ, CA, CO, CT, DC, DE, FL, GA, GU, HI, IA, ID, IL, IN, KS, KY, LA, MA, MD, ME, MI, MN, MO, MP, MS, MT, NA, NC, ND, NE, NH, NJ, NM, NV, NY, OH, OK, OR, PA, PR, RI, SC, SD, TN, TX, UT, VA, VI, VT, WA, WI, WV, WY
coalmine_eia923

field
description
resources

avg_num_employees
Average number of employees.
plants_hydro_ferc1, plants_pumped_storage_ferc1

Average number of plant employees during report year.
plants_steam_ferc1

boiler_id
Boiler identification code. Alphanumeric.
boiler_fuel_eia923

EIA-assigned boiler identification code.
boiler_generator_assn_eia860

The EIA-assigned boiler identification code. Alphanumeric.
boilers_entity_eia

capacity_mw
Name plate capacity in megawatts.
plants_small_ferc1

The highest value on the generator nameplate in megawatts rounded to the nearest tenth.
generators_eia860

Total installed (nameplate) capacity, in megawatts.
plants_hydro_ferc1, plants_pumped_storage_ferc1

Total installed plant capacity in MW.
plants_steam_ferc1

capex_per_mw
Capital expenses per MW of installed plant capacity.
plants_steam_ferc1

Cost of plant per megawatt of installed (nameplate) capacity. Nominal USD.
plants_hydro_ferc1, plants_pumped_storage_ferc1

Plant costs (including asset retirement costs) per megawatt. Nominal USD.
plants_small_ferc1

city
Name of the city in which operator/owner is located
utilities_eia860

The plant's city.
plants_entity_eia

construction_year
Four digit year of the plant's original construction.
plants_hydro_ferc1, plants_pumped_storage_ferc1

Original year of plant construction.
plants_small_ferc1

Year the plant's oldest still operational unit was built.
plants_steam_ferc1

description
Description of the FERC depreciation account, as listed on FERC Form 1, Page 219.
ferc_depreciation_lines

Long description of the FERC Account.
ferc_accounts

fuel_cost_per_mmbtu
All costs incurred in the purchase and delivery of the fuel to the plant in cents per million Btu(MMBtu) to the nearest 0.1 cent.
fuel_receipts_costs_eia923

Average cost of fuel consumed in the report year, in nominal USD per mmBTU of fuel heat content.
fuel_ferc1

Average fuel cost per mmBTU (if applicable). Nominal USD.
plants_small_ferc1

fuel_mmbtu_per_unit
Average heat content of fuel consumed in the report year, in mmBTU per reported fuel unit.
fuel_ferc1

Heat content of the fuel in millions of Btus per physical unit.
generation_fuel_eia923, boiler_fuel_eia923

fuel_type
Kind of fuel. Originally reported to FERC as a freeform string. Assigned a canonical value by PUDL based on our best guess.
plants_small_ferc1

The fuel code reported to EIA. Two or three letter alphanumeric.
generation_fuel_eia923

fuel_type_code_pudl
PUDL assigned code indicating the general fuel type.
fuel_ferc1

Standardized fuel codes in PUDL.
generators_eia860, fuel_receipts_costs_eia923, generation_fuel_eia923, boiler_fuel_eia923

generator_id
EIA-assigned generator identification code.
boiler_generator_assn_eia860

Generator identification code. Often numeric, but sometimes includes letters. It's a string!
generation_eia923

Generator identification number
generators_entity_eia

Generator identification number.
generators_eia860, ownership_eia860

installation_year
Four digit year in which the last unit was installed.
plants_hydro_ferc1, plants_pumped_storage_ferc1

Year the plant's most recently built unit was installed.
plants_steam_ferc1

line_id
A human readable string uniquely identifying the FERC depreciation account. Used in lieu of the actual line number, as those numbers are not guaranteed to be consistent from year to year.
ferc_depreciation_lines

Line numbers, and corresponding FERC account number from FERC Form 1, page 2019, Accumulated Provision for Depreciation of Electric Utility Plant (Account 108).
accumulated_depreciation_ferc1

net_generation_mwh
Net generation (exclusive of plant use) in MWh during report year.
plants_steam_ferc1

Net generation excluding plant use, in megawatt-hours.
plants_small_ferc1

Net generation for specified period in megawatthours (MWh).
generation_eia923

Net generation, exclusive of plant use, in megawatt hours.
plants_hydro_ferc1, plants_pumped_storage_ferc1

Net generation, year to date in megawatthours (MWh). This is total electrical output net of station service. In the case of combined heat and power plants, this value is intended to include internal consumption of electricity for the purposes of a production process, as well as power put on the grid.
generation_fuel_eia923

peak_demand_mw
Net peak demand experienced by the plant in MW in report year.
plants_steam_ferc1

Net peak demand for 60 minutes. Note: in some cases peak demand for other time periods may have been reported instead, if hourly peak demand was unavailable.
plants_small_ferc1

Net peak demand on the plant (60-minute integration), in megawatts.
plants_hydro_ferc1, plants_pumped_storage_ferc1

plant_capability_mw
Net continuous plant capability in MW
plants_steam_ferc1

Net plant capability in megawatts.
plants_pumped_storage_ferc1

plant_hours_connected_while_generating
Hours the plant was connected to load while generating.
plants_hydro_ferc1, plants_pumped_storage_ferc1

Total number hours the plant was generated and connected to load during report year.
plants_steam_ferc1

plant_name_ferc1
Name of the plant, as reported to FERC. This is a freeform string, not guaranteed to be consistent across references to the same plant.
fuel_ferc1, plants_ferc1, plants_hydro_ferc1, plants_pumped_storage_ferc1, plants_steam_ferc1

PUDL assigned simplified plant name.
plants_small_ferc1

plant_type
Kind of plant (Run-of-River or Storage).
plants_hydro_ferc1

PUDL assigned plant type. This is a best guess based on the fuel type, plant name, and other attributes.
plants_small_ferc1

Simplified plant type, categorized by PUDL based on our best guess of what was intended based on freeform string reported to FERC. Unidentifiable types are null.
plants_steam_ferc1

prime_mover_code
Code for the type of prime mover (e.g. CT, CG)
boilers_entity_eia

EIA assigned code for the prime mover (i.e. the engine, turbine, water wheel, or similar machine that drives an electric generator)
generators_entity_eia

Type of prime mover.
generation_fuel_eia923

state
Plant state. Two letter US state and territory abbreviations.
plants_entity_eia

State of the operator/owner
utilities_eia860

State the plant is located in.
hourly_emissions_epacems

Two letter US state abbreviations and three letter ISO-3166-1 country codes for international mines.
coalmine_eia923

street_address
Plant street address
plants_entity_eia

Street address of the operator/owner
utilities_eia860

utility_id_eia
EIA-assigned identification number for the company that is responsible for the day-to-day operations of the generator.
generators_eia860, ownership_eia860, plants_eia860, utilities_eia860

The EIA Utility Identification number.
utilities_eia, utilities_entity_eia

zip_code
Plant street address
plants_entity_eia

Zip code of the operator/owner
utilities_eia860

I almost certainly typed most of these back in the day.

state will need to be reorganized in some cases I think, and the enums may need to be customized by field? For the US political subdivisions that have a 2 letter abbreviation, maybe we call these columns something like us_state_territory? and that could include DC, Guam, Virgin Islands, Puerto Rico, etc. For coalmine_eia923 I think we probably want to split it into two columns, one which the 3-letter ISO country abbreviation, and another which is the US state or territory abbreviation. For the purposes of column value constraints, I suspect that we will be okay with having all of the 2-letter abbreviations of US political subdivisions. However there are some iteration cases (e.g. in the CEMS) where we want only to iterate over a subset of those abbreviations and that subset will need to be defined elsewhere.  Oh also I think there are some places where Canadian provinces have snuck in, and at this point I've probably replaced them all with CAN, but if we have state-or-territory and also country... maybe we need to think about this more...
I suspect that the multiply defined columns from ferc1 mostly all refer to the same thing, but they may be written differently on the different pages of the blank PDF, which is where these descriptions would have come from. We will need to review and make sure they actually mean the same thing between say, the steam and small plants tables, but I think in most cases they will.
city really is referring to two different things: where a plant is, vs. the city where a utility's offices / mailing address are. So these should maybe get renamed like... plant_city and utility_city or something like that?
All the "nominal USD" comments can probably be removed, since all of the costs are in USD, and they're all nominal (not inflation adjusted)
fuel_type is fraught. There are many, many different categorizations. They should probably all indicate where they came from in the column name. E.g. fuel_type_eia or fuel_type_ferc1 or fuel_type_pudl
generator_id really is all the same, but it should probably become generator_id_eia and all the descriptions should be the same and they are hella not numbers. definitely strings. But lots of numbers. And this fucks up the data types all the time when you only read a subset of them.
Not sure what is going on with line_id -- looks weird.
mine_id_pudl should definitely be the same. Probably should combine the two -- yes it's a surrogate key that we made, and also it identifies a mine.
plant_*_ferc1 there's some now abandoned table cleanup that was being applied to the small plants table, which we may need to remediate.
plant_type has different valid values in different plant tables. Might need to make more specific names, or combine all of the valid values across the tables into a single enum and a single more general plant type description.
prime_mover_code is all the same I think. We have also talked about replacing many of the inscrutable short codes with longer snake_case descriptions that are actually readable, and using an ENUM to constrain them.
state descriptions are referring to different things. Probably need to rename some columns utility/operator state vs. plant state
street_address ditto city and state.
I think utility_id_eia should all be the same, though only one of those descriptions would make sense in all contexts. There are cases in which there's an owner vs. operator distinction, and "utility" is kind of the generic name we've used when it doesn't matter.
zip_code also needs to differentiate plant vs. corporate entity.

After reading through all of these, I agree w/ a lot of what zane said. Outside of the enums the columns in here that seem like they need to be broken out are:

street_address
zip_code
fuel_type

I have apprehension about breaking out fuel_type into fuel_type_eia and fuel_type_ferc1 because we have conveniently squished them to be comparable/merge-able columns, but they are generated in very different ways.

All the unresolved fields listed above have been added to pudl.metadata.fields with only a name and a type. You can fill in their description and constraints.enum (or rename them) as you decide how to resolve them. As needed, you can override the default field metadata for a particular resource in the resource's metadata in pudl.metadata.resources:
'resource': {
    'schema': {
        'fields': ['default_field', {'name': 'custom_field', 'description': 'Custom description'}]
    }
}


Datepicker on:dateSelected could be documented as well

Datepicker dispatches dateSelected which is not documented. I think it should be documented.

It's documented here: https://6edesign.github.io/svelte-calendar/
If you think it should be in the readme too, please open a PR.

@daliusd can you close this please :)


write tests using bats framework

Ever wrote tests for a script?
We need to use bats
Check out projects using bats for examples
Since this is a weird use case, we need to figure out what things to test or not. Suggestions are welcome

@Bhupesh-V I'd like to work on this.
Do you have something in mind that we could use as a baseline?

@Bhupesh-V I'd like to work on this.
Do you have something in mind that we could use as a baseline?

Hey have been doing some research, seems like there is lot to think about. The fundamental problem to figure out is how do we mock the execution of fzf command in bats. Since its deeply integrated within ugit.
Another tool I tried using was shellspec for testing, but as it turns out it doesn't support testing colored output.
Ref: https://github.com/shellspec/shellspec/issues/278
Not really sure how to proceed further at the moment. If you are able to find something, do let me know in the thread.

Another tool I tried using was shellspec for testing, but as it turns out it doesn't support testing colored output.
Ref: https://github.com/shellspec/shellspec/issues/278

See my answer on that issue...
The solution to make it work is to use custom matchers.


Benchmarking errors out for GPTJ_6B model on single L4 GPU due to CUDA ERROR: 2

I am running benchmarking script for GPTJ-6B model on a single NVIDIA L4 GPU and it errors out.
Error
[10/24/2023-13:31:01] [TRT] [I] [MemUsageStats] Peak memory usage of TRT CPU/GPU memory allocators: CPU 0 MiB, GPU 16385 MiB
[10/24/2023-13:31:01] [TRT] [I] [MemUsageChange] TensorRT-managed allocation in building engine: CPU +0, GPU +11542, now: CPU 0, GPU 11542 (MiB)
[10/24/2023-13:31:01] [TRT] [V] Adding 1 engine(s) to plan file.
[10/24/2023-13:31:10] [TRT] [I] [MemUsageStats] Peak memory usage during Engine building and serialization: CPU: 25877 MiB
[10/24/2023-13:31:10] [TRT-LLM] [I] Total time of building gptj_6b_float16_tp1_rank0.engine: 00:00:45
[10/24/2023-13:31:10] [TRT] [I] Loaded engine size: 11543 MiB
[10/24/2023-13:31:12] [TRT] [V] Local registry did not find Lookup creator. Will try parent registry if enabled.
[10/24/2023-13:31:12] [TRT] [V] Global registry found Lookup creator.
...
...
[10/24/2023-13:31:12] [TRT] [V] Loaded shared library libcublas.so.12
[10/24/2023-13:31:12] [TRT] [V] Using cublas as plugin tactic source
[10/24/2023-13:31:12] [TRT] [I] [MemUsageChange] Init cuBLAS/cuBLASLt: CPU +0, GPU +8, now: CPU 25256, GPU 12890 (MiB)
[10/24/2023-13:31:12] [TRT] [V] Trying to load shared library libcudnn.so.8
[10/24/2023-13:31:12] [TRT] [V] Loaded shared library libcudnn.so.8
[10/24/2023-13:31:12] [TRT] [V] Using cuDNN as plugin tactic source
[10/24/2023-13:31:12] [TRT] [I] [MemUsageChange] Init cuDNN: CPU +0, GPU +8, now: CPU 25256, GPU 12898 (MiB)
[10/24/2023-13:31:12] [TRT] [V] Deserialization required 2677906 microseconds.
[10/24/2023-13:31:12] [TRT] [I] [MemUsageChange] TensorRT-managed allocation in engine deserialization: CPU +0, GPU +11541, now: CPU 0, GPU 11541 (MiB)
Traceback (most recent call last):
  File "/code/tensorrt_llm/benchmarks/python/benchmark.py", line 322, in <module>
    main(args)
  File "/code/tensorrt_llm/benchmarks/python/benchmark.py", line 219, in main
    benchmarker = GPTBenchmark(
  File "/code/tensorrt_llm/benchmarks/python/gpt_benchmark.py", line 173, in __init__
    self.decoder = tensorrt_llm.runtime.GenerationSession(
  File "/usr/local/lib/python3.10/dist-packages/tensorrt_llm/runtime/generation.py", line 306, in __init__
    self.runtime = _Runtime(engine_buffer, mapping)
  File "/usr/local/lib/python3.10/dist-packages/tensorrt_llm/runtime/generation.py", line 143, in __init__
    self.__prepare(mapping, engine_buffer)
  File "/usr/local/lib/python3.10/dist-packages/tensorrt_llm/runtime/generation.py", line 163, in __prepare
    address = CUASSERT(cudart.cudaMalloc(self.engine.device_memory_size))[0]
  File "/usr/local/lib/python3.10/dist-packages/tensorrt_llm/runtime/generation.py", line 92, in CUASSERT
    raise RuntimeError(
RuntimeError: CUDA ERROR: 2, error code reference: https://nvidia.github.io/cuda-python/module/cudart.html#cuda.cudart.cudaError_t
Exception ignored in: <function _Runtime.__del__ at 0x7fd52269e830>
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/tensorrt_llm/runtime/generation.py", line 232, in __del__
    cudart.cudaFree(self.address)
AttributeError: '_Runtime' object has no attribute 'address'

Command used
python benchmark.py \
    -m gptj_6b \
    --mode plugin \
    --batch_size 1 \
    --dtype float16 \
    --input_output_len "128,20" \
    --log_level verbose

Output from nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.125.06   Driver Version: 525.125.06   CUDA Version: 12.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA L4           Off  | 00000000:00:03.0 Off |                    0 |
| N/A   68C    P0    34W /  72W |      0MiB / 23034MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Same issue to https://github.com/NVIDIA/TensorRT-LLM/issues/85.

Closing as duplicate


It doesn't work.

The command I input was "trans :en '工作'"

I used to get the right answer. But recently it doesn't work.
OS: BigSur 11.4
Device: MacBook Pro 2020(Apple chip)

Please read https://github.com/soimort/translate-shell/blob/develop/CONTRIBUTING.md and follow the steps.

The version:

The result I expect

As you can see， now it works. However, it doesn't work sometimes, for example , in this afternoon( UTC +8:00 ).


fixes bug introduced in #292 look up in array of strings instead of classes

SimpleForm detection was using the wrong class name, and the ancestor array needed to be an array of strings.

Nice one. A little bit worried, because this seemed to be working for me, so which version of simple-form did you test with? So I can verify this.

3.2.0

On Jan 27, 2016, at 10:11 AM, Nathan Van der Auwera<EMAIL_ADDRESS>wrote:
Nice one. A little bit worried, because this seemed to be working for me, so which version of simple-form did you test with? So I can verify this.
—
Reply to this email directly or view it on GitHub.

I'm also using rails 4 and when I noticed that the alignment of the dynamic items was wrong, I placed byebug after the method_name assignment in the render_association method and when I checked its value I noticed that it was using fields_for instead of simple_fields_for...

Great! Awesome, this was always wrong. And I probably never stumbled across it, because the simple_fields_for is just a very thin wrapper around the fields_for, unless of course you do something special I guess :)


YUICompressor exceptions

YUICompressor Exception should be more detailed.
Minify_YUICompressor::_prepare() should be changed to:

    private static function _prepare()
    {
        if (!is_file(self::$jarFile)) {
            throw new Exception('Minify_YUICompressor: $jarFile
('.self::$jarFile.') is not a valid file.');
        }
        if (!is_dir(self::$tempDir)) {
            throw new Exception('Minify_YUICompressor: $tempDir
('.self::$tempDir.') is not a valid direcotry.');
        }
        if (!is_writable(self::$tempDir)) {
            throw new Exception('Minify_YUICompressor: $tempDir
('.self::$tempDir.') is not writable.');
        }
    }

Minify version: 2.1.3
PHP version: 5.3

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 22 Dec 2009 at 7:50

Good idea. Thanks.

Original comment by<EMAIL_ADDRESS>on 22 Dec 2009 at 8:00

Changed state: Accepted

ok, nvm, it is closed, i mislooked it status "verified" as state

Original comment by<EMAIL_ADDRESS>on 30 Mar 2012 at 10:14

i mean "those checks are in 2.1.5 release", so you can close the ticket :)

Original comment by<EMAIL_ADDRESS>on 30 Mar 2012 at 10:13

This seems to be in (at least) 2.1.5!

Original comment by<EMAIL_ADDRESS>on 29 Mar 2012 at 7:51

Thanks for catching these.

Original comment by<EMAIL_ADDRESS>on 29 Mar 2012 at 8:13

Changed state: Verified


pylint: enable used-before-assignment

A very minor fix and enable used-before-assignment.
Relates to #9614

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
13 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.001%) to 85.965%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/vf2_layout.rs
3
94.74%

crates/qasm2/src/lex.rs
4
91.14%

crates/qasm2/src/parse.rs
6
97.58%

Totals

Change from base Build<PHONE_NUMBER>:
0.001%

Covered Lines:
71488

Relevant Lines:
83159

💛  - Coveralls


Clarification on Version 0.10.0 and 0.10.1 Fork

Could you please clarify why versions 0.10.0 and 0.10.1 have diverged? This is rather confusing. It seems that version 0.10.0 not only updated the interface but also fixed some bugs. However, these fixes do not appear to have been merged into version 0.10.1. Could you share the next steps in your plan? Thank you!

Hi @ppcfan, @ZachNagengast will chime in soon but here is a quick summary: v0.10.0 will be yanked due to an issue so please rely on v0.10.1.

Yep, sorry for the confusion @ppcfan the release branch was created based on the pre-squashed version of this pull request #282, which then became the branch that went into the release and had different histories. The diffs are actually the same if you compare the diff, just has different commits. Will remove that version since the patch v0.10.1 has the history from main.
Diffs for comparison:
https://github.com/argmaxinc/WhisperKit/compare/v0.10.1...2b4c011b76bce78b4202f756cd2a9b94d582c850^^^


NO access to LiveBox in Spain. Same error as above.

Hello,
I have the same problem here on Spain Orange Livebox router, "Unknown error", inserting user/password info.
This could be by the software version.
Do you know which can be the trouble?
John

http://<IP_ADDRESS>/ws
With this info:   "Not Found"
Json not working?

@soshedro it's the same with http://livebox.home/ws ?

Please enable debug mode in Home assistant
homeassistant.custom_components.livebox: debug in log section
And paste result

I getting some problems here too. I need to install another but don't know how.
Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/loader.py", line 541, in _load_file     module = importlib.import_module(path)   File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module     return _bootstrap._gcd_import(name[level:], package, level)   File "<frozen importlib._bootstrap>", line 1014, in _gcd_import   File "<frozen importlib._bootstrap>", line 991, in _find_and_load   File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked   File "<frozen importlib._bootstrap>", line 671, in _load_unlocked   File "<frozen importlib._bootstrap_external>", line 783, in exec_module   File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed   File "/config/custom_components/livebox/__init__.py", line 14, in <module>     from .bridge import BridgeData   File "/config/custom_components/livebox/bridge.py", line 4, in <module>     from aiosysbus import AIOSysbus ModuleNotFoundError: No module named 'aiosysbus'

I getting some problems here too. I need to install another but don't know how.
Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/loader.py", line 541, in _load_file     module = importlib.import_module(path)   File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module     return _bootstrap._gcd_import(name[level:], package, level)   File "<frozen importlib._bootstrap>", line 1014, in _gcd_import   File "<frozen importlib._bootstrap>", line 991, in _find_and_load   File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked   File "<frozen importlib._bootstrap>", line 671, in _load_unlocked   File "<frozen importlib._bootstrap_external>", line 783, in exec_module   File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed   File "/config/custom_components/livebox/__init__.py", line 14, in <module>     from .bridge import BridgeData   File "/config/custom_components/livebox/bridge.py", line 4, in <module>     from aiosysbus import AIOSysbus ModuleNotFoundError: No module named 'aiosysbus'

Same problem here
Log error:
ERROR (MainThread) [custom_components.livebox.bridge] Error Not open (Open session failed (APIResponse: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))).

Same problem here
Log error:
ERROR (MainThread) [custom_components.livebox.bridge] Error Not open (Open session failed (APIResponse: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')))).

Same here.
http://<IP_ADDRESS>/ws
With this info: "Not Found"

@soshedro it's the same with http://livebox.home/ws ?

Yes, same here:

Yes, same error as other users said. "404"

same error here @spain

Do you know the url that we should call because in France, we have a / WS

I don't know, is there a way to scrape it? I know the firmware might have been altered here for security purposes.

It would be necessary to activate the Developer mode on Chrome and browse the Livebox to see which calls are

I don't know, is there a way to scrape it? I know the firmware might have been altered here for security purposes.

I had a look at the Network requests in chrome while navigating my router configuration screens. It seems all requests go directly to http://<IP_ADDRESS>:80 so no path with /ws
All web resources are get like:

http://<IP_ADDRESS>/js
http://<IP_ADDRESS>/css
http://<IP_ADDRESS>/images
http://<IP_ADDRESS>/cgi

Is there anything else that I can do or look for?

The /ws interface allows to control the exposed webservices unfortunately with these elements I can't do anything.
It is necessary to identify the calls to the API


RA-1232 search by framework

As part of the story I have introduced some dependency injection of IMapper and IElasticClient. There's some other improvements but not required for this story.

A few more commits for you to review. @sachpatel @dev4valtech @chrisjensenuk .