text:
create_vm fails with postgres SQL error with CPI v72

Describe the bug
create_vm fails with postgres SQL error with CPI v72
To Reproduce
cloud_config extract :
...

name: tf-net-osb-data-plane-dedicated-priv
subnets:

azs:

z1
z2
z3
cloud_properties:
name: vxw-dvs-27-virtualwire-99-sid-7050-VXS_in_tf-net-osb-data-plane-dedicated-priv
gateway: 192.168.61.1
range: 192.168.61.0/24
reserved:
192.168.61.1 - 192.168.61.20
...

CPI Error Log
D, [2021-12-02T15:03:31.712189 #11308] [task:5894640] DEBUG -- DirectorJobRunner: (0.000524s) (conn: 47264853264400) UPDATE "tasks" SET "event_output" = ("event_output" || '{"time":1638457411,"error":{"code":100,"message":"PG::InvalidTextRepresentation: ERROR:  invalid input syntax for type boolean: "cloud_properties"\nLINE 1: ...68.61.34'') AND (''netmask'' = ''255.255.255.0'') AND (''cloud_pro...\n                                                             ^\n"}}
') WHERE ("id" = 5894640)
D, [2021-12-02T15:03:31.752886 #11308] [task:5894640] DEBUG -- DirectorJobRunner: (0.040494s) (conn: 47264853264400) COMMIT
E, [2021-12-02T15:03:31.753338 #11308] [task:5894640] ERROR -- DirectorJobRunner: PG::InvalidTextRepresentation: ERROR:  invalid input syntax for type boolean: "cloud_properties"
LINE 1: ...68.61.34') AND ('netmask' = '255.255.255.0') AND ('cloud_pro...
^
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:152:in exec' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:152:in block in execute_query'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/database/logging.rb:43:in log_connection_yield' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:152:in execute_query'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:140:in block in execute' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:116:in check_disconnect_errors'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:140:in execute' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:496:in _execute'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:314:in block (2 levels) in execute' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:518:in check_database_errors'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:314:in block in execute' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/connection_pool/threaded.rb:88:in hold'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:270:in synchronize' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:314:in execute'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/dataset/actions.rb:1083:in execute' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/postgres.rb:610:in fetch_rows'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/dataset/actions.rb:937:in with_sql_each' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/dataset/actions.rb:945:in with_sql_first'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/adapters/shared/postgres.rb:1553:in insert_select' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1709:in _insert_select_raw'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1682:in _insert' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1753:in block (2 levels) in _save'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1015:in around_create' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1750:in block in _save'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1015:in around_save' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1745:in _save'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1465:in block (2 levels) in save' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1905:in block in checked_transaction'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:245:in _transaction' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:220:in block in transaction'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/connection_pool/threaded.rb:92:in hold' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:270:in synchronize'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:186:in transaction' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1905:in checked_transaction'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1465:in block in save' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1893:in checked_save_failure'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1465:in save' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:254:in create'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/api/event_manager.rb:42:in create_event' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/deployment_plan/steps/create_vm_step.rb:166:in add_event'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/deployment_plan/steps/create_vm_step.rb:162:in ensure in create' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/deployment_plan/steps/create_vm_step.rb:162:in create'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/deployment_plan/steps/create_vm_step.rb:27:in perform' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/step_executor.rb:39:in block in run_agenda'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/step_executor.rb:36:in each' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/step_executor.rb:36:in run_agenda'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/step_executor.rb:21:in block (5 levels) in run' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/event_log.rb:105:in advance_and_track'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/step_executor.rb:20:in block (4 levels) in run' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh_common-0.0.0/lib/common/thread_formatter.rb:50:in with_thread_name'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh-director-0.0.0/lib/bosh/director/step_executor.rb:18:in block (3 levels) in run' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh_common-0.0.0/lib/common/thread_pool.rb:77:in block (2 levels) in create_thread'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh_common-0.0.0/lib/common/thread_pool.rb:63:in loop' /var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/bosh_common-0.0.0/lib/common/thread_pool.rb:63:in block in create_thread'
/var/vcap/data/packages/director/87427387c8b374a15842eb951bb2cef3b10afb12/gem_home/ruby/2.6.0/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'
D, [2021-12-02T15:03:31.755025 #11308] [task:5894640] DEBUG -- DirectorJobRunner: (0.000375s) (conn: 47264853268480) SELECT * FROM "tasks" WHERE "id" = 5894640
D, [2021-12-02T15:03:31.757519 #11308] [task:5894640] DEBUG -- DirectorJobRunner: (0.000131s) (conn: 47264854487260) BEGIN
D, [2021-12-02T15:03:31.758981 #11308] [task:5894640] DEBUG -- DirectorJobRunner: (0.000611s) (conn: 47264854487260) UPDATE "tasks" SET "state" = 'error', "timestamp" = '2021-12-02 15:03:31.756516+0000', "description" = 'create deployment', "result" = 'PG::InvalidTextRepresentation: ERROR:  invalid input syntax for type boolean:
LINE 1: ...68.61.34'') AND...', "output" = '/var/vcap/store/director/tasks/5894640', "checkpoint_time" = '2021-12-02 15:03:14.991645+0000', "type" = 'update_deployment', "username" = 'admin', "deployment_name" = 'y_7186f856-b982-41f9-9e60-c28dae205d1b', "started_at" = '2021-12-02 15:02:44.991574+0000', "event_output" = '{"time":1638457369,"stage":"Preparing deployment","tags":[],"total":1,"task":"Preparing deployment","index":1,"state":"started","progress":0}
Expected behavior
success for create_vm
Release Version & Related Info (please complete the following information):

CPI : 72
BOSH Director : 271.8.0
Stemcell : Bionic 1.34
vCenter : 6.7

Additional context
Bump CPI from v66 to v72

@JCL38-ORANGE Just to double-check, the snippet to reproduce this issue is:
networks:
- name: tf-net-osb-data-plane-dedicated-priv
  subnets:
    azs:
    - z1
    - z2
    - z3
    cloud_properties:
      name: vxw-dvs-27-virtualwire-99-sid-7050-VXS_in_tf-net-osb-data-plane-dedicated-priv
    gateway: 192.168.61.1
    range: 192.168.61.0/24
    reserved:
    - 192.168.61.1 - 192.168.61.20

Just want to make sure that the snippet used was actually valid yaml (the snippet you posted is not, but this could just be a markdown issue).

Hello,
Sorry for my very late answer.
Yes I confirm your snippet.
Thanks and regards,
Jean-Christophe.

repo: cloudfoundry/bosh-vsphere-cpi-release


text:
Deploy standalone Eirini

Background
So far, we've been using a pared down cf-for-k8s to deploy Eirini. This is sub optimal and couples explorations to the cf-for-k8s project, with all the dependencies and configuration specifics for a cf-for-k8s cluster.
Deliverable

Instructions to deploy a standalone Eirini Controller (or Eirini if the Controller is not sufficient).
If deployment configuration is required, that configuration should also be delivered to this repo.

Dev Notes

Work should be delivered on a branch, using a PR workflow referencing this issue

Once this issue is completed, we should be able to use a helm chart in the standalone eirini-controller repo to deploy.

Instructions on how to deploy are here: https://github.com/cloudfoundry-incubator/eirini-controller/blob/master/README.md
I think this story just becomes updating our README to reference this.

source: gharchive/issue

authors: Birdrock angelachin

repo: cloudfoundry/cf-crd-explorations

license_type: permissive

license_source: github-api


text:
Delete Orphaned Routes gives 400 for routes with service instance associations

Command
cf delete-orphaned-routes
What occurred, incl. error and/or stack trace
I created two routes, one associated with an app, the other with a service:

space          host     domain            port   path   type   apps     service
pcfdev-space   my-app   local.pcfdev.io                        my-app
pcfdev-space   pebble   example.com                                     testups

I would expect delete orphaned routes to no-op, as no routes are orphaned. Instead it gives an error:
FAILED
Server error, status code: 400, error code: 10006, message: Please delete the service_instance associations for your routes.

What you expected to occur
No deletion and no error
CLI Version
6.22.2+a95e24c-2016-10-27
CC API Endpoint Version
2.58.0
CF Trace, if issue relates to HTTP requests or strange behavior
See https://gist.github.com/twoseat/7dab66b7aa85074feacec76d636cf9c3
Platform & Shell Details
macOS Sierra and stock Terminal
Any other relevant information
Running against pcfdev 0.21
Note that as part of the fix the help text should be changed from:
Delete all orphaned routes (i.e. those that are not mapped to an app)
to something like:
Delete all orphaned routes (i.e. those that are not mapped to an app or service)

Command
cf delete-orphaned-routes

What occurred, incl. error and/or stack trace
I created two routes, one associated with an app, the other with a service:

space          host     domain            port   path   type   apps     service
pcfdev-space   my-app   local.pcfdev.io                        my-app
pcfdev-space   pebble   twoseat.com                                     testups

I would expect delete orphaned routes to no-op, as no routes are orphaned. Instead it gives an error:
FAILED
Server error, status code: 400, error code: 10006, message: Please delete the service_instance associations for your routes.

What you expected to occur
No deletion and no error

CLI Version
6.22.2+a95e24c-2016-10-27

CC API Endpoint Version
2.58.0

CF Trace, if issue relates to HTTP requests or strange behavior
See https://gist.github.com/twoseat/7dab66b7aa85074feacec76d636cf9c3

Platform & Shell Details
macOS Sierra and stock Terminal

Any other relevant information
Running against pcfdev 0.21

CC: @shalako
@twoseat As the purpose of a route service is to add preprocessing to application requests, if a route is only bound to a route service and not to an app, it is basically orphaned (in a way, the whole route service is). Hence such routes should be deleted as well?

Seems like either:

routes bound to services but not apps are considered orphaned, and the command should delete the route and leave the service instance, requiring the cli to unbind the service first. the user should not receive a request to unbind them.

or

routes bound to services but not apps are not considered orphaned, so the cli should not attempt to delete them, and the user wouldn't see the must-unbind-first error.

Given current ux I tend to agree with Dies (option 1), but looking forward we may eventually fulfill some interesting use cases in which routes don't have to be mapped to apps. For this reason, and because it's lower impact, while improving current UX, I'm inclined to suggest #2.

I'm a relatively naive user, so my expectation that the service route would be deleted is of limited value. Either of @shalako's options sound reasonable to me, so long as we don't get the current 400!

Hi @twoseat thanks for creating this issue. We believe the issue you described above will be fix when we address #746. We will leave this issue open to ensure that will be indeed the case.

This issue was resolved by https://github.com/cloudfoundry/cli/pull/1543 and will be fixed in the next release of the CF CLI.

authors: XenoPhex dkoper shalako twoseat willmurphyscode

repo: cloudfoundry/cli


text:
Log streaming services can't provide multiple syslog_drain_url

Issue
Log streaming services can't provide multiple syslog_drain_url
Context
Currently a log streaming service can only provide a single URL in the binding response.

syslog_drain_url	string	A URL to which logs may be streamed. "requires":["syslog_drain"] must be declared in the Catalog endpoint or the platform should consider the response invalid.
https://docs.cloudfoundry.org/services/api.html#binding

In certain setups it would be desirable to allow multiple URLs to be provided for availability and load balancing purposes.
Steps to Reproduce
Bind a log streaming service with multiple syslog_drain_url to an app
Expected result
Either of:

Logs are streamed to one of the the syslog_drain_url; if this becomes unavailable a new connection is opened to one of the other syslog_drain_url provided and logs resume streaming (for availability)
Each currently available syslog_drain_url receives a "subset" of the logs in parallel (for availability and load balancing)

Current result
Not supported. Only one syslog_drain_url can be provided. If this become unavailable logs are irretrievably lost.

Hey @CAFxX,
Thank you for your feature request.
Since this is part of the open service broker specification, you would have to submit this issue on their github.
A couple idea that may or may not address your use-case:

Users can bind multiple logging services to a single app for higher availability (at the cost of duplication)
The logging service can do its own load balancing behind the single url

I'm going to close this issue for now, but please re-open it if you have questions or concerns.

@gerg && @ericpromislow

authors: CAFxX Gerg


text:
Encryptor fips

I updated lib/cloud_controller/encryptor.rb so that it can be used when OpenSSL::fips_mode = true is set.  This required moving off of the (deprecated) keyivgen method and following the better practice of using a random IV for every message, which IV is then returned as part of the encrypted string for use in decryption.  I updated the spec file so that it enables fips_mode, but I tagged this so that you can avoid enabling fips mode with rspec -t ~fips.
RSPEC:
[sandy@oc1718273258 cloud_controller_ng]$ bundle exec rspec spec/unit/lib/cloud_controller/encryptor_spec.rb
.......................
Finished in 3.38 seconds (files took 42.58 seconds to load)
23 examples, 0 failures
RSPEC (fips disabled):
[sandy@oc1718273258 cloud_controller_ng]$ bundle exec rspec -t ~fips spec/unit/lib/cloud_controller/encryptor_spec.rb
Run options: exclude {:fips=>true}
......................
Finished in 3.01 seconds (files took 1 minute 6.34 seconds to load)
22 examples, 0 failures
RUBOCOP:
[sandy@oc1718273258 cloud_controller_ng]$ bundle exec rubocop
warning: parser/current is loading parser/ruby21, which recognizes
warning: 2.1.5-compliant syntax, but you are running 2.1.6.
Inspecting 1228 files
[...]
1228 files inspected, no offenses detected

bundle exec rake spec on my system runs successfully w/o errors.  I will work on a modification to encryptor_spec.rb to let it run with a non-FIPS OpenSSL.

I've decided to close this for now - I need to rethink how to introduce this, and I think it will involve retaining the current (IMHO, less-than-ideal) encryption while enabling FIPS mode via a configuration flag or similar (with it disabled by default).

Hi @ScarletTanager,
There is a desire to have the ability to rotate the encryption keys used with CloudController. No work has been scheduled, but that work might overlap nicely with this effort. There is some context on the cf-dev mailing list:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000416.html

source: gharchive/pull-request

authors: ScarletTanager jpalermo


text:
[RFC] Cleanup Stemcells

Proposal to start cleanup up stemcells after x amount of year(s).

cc @cloudfoundry/foundational-infrastructure-wg

Can you link to, or provide, the rough estimate that this would save 10s of thousands of dollars (per year)?
Seems worthwhile even if it only saves thousands of dollars per year.
If someone really wants to recreate CF from 2012, they'd still be able to build their own stemcell, right?

For the light stemcells it is dependent on the cloud provider.   I would suggest following the cloud provider policies.  If that is not reasonable, I do not understand why the light stemcells would be retired any sooner than the heavy stemcells?

If the light stemcell is somehow available from the Cloud Provider, maybe point to where it is stored by Cloud Provider.

That's exactly the problem for AWS case, light stemcells are hosted in "our" accounts. One copy per region served and unlike heavy stemcells (served from S3 buckets and global) they do not support cheaper storage classes. They're basically EBS snapshots lying around in some account that people can access.

If the light stemcell is somehow available from the Cloud Provider, maybe point to where it is stored by Cloud Provider.

If someone really wants to recreate CF from 2012, they'd still be able to build their own stemcell, right?

Yep someone could build their own old stemcell using https://github.com/cloudfoundry/bosh-linux-stemcell-builder

I think that removing old stemcells is an excellent idea. Older stemcells have known security vulnerabilities and weaknesses, so getting rid of them reduces the chances of someone accidentally using them (and also reduces hosting costs). Would be good to do a similar exercise with the java-buildpack assets.. getting rid of the known-vulnerable and obsolete versions of tomcat, jdk etc.

An ex-Pivotal account that hosts public facing AMIs and has 30541 EBS snapshots aged 6 months or more, with the oldest snapshot created in 2016. Even though storing a snapshot costs about 15 cents per month, the aggregate spend is currently about $3.3K per month, or $40K per year.

in total its about 20cent per stemcell per region as the ami itself also cost money.
as we push to 19 regions including 2 gov regions.
it will cost roughly 3.80 per stemcell

Cost example for AWS lite stemcells:
15 cents per month per snapshot * 19 regions (including 2 gov regions) = 2,85 dollar per month per stemcell
Lets assume a stemcell every 3 weeks (more if high CVE's are released) 52/3 * annual cost per stemcell (2,85*12) = $600 dollar per year.
If we would keep 3 years of light stemcells that would cost around $1800 per year. Not accounting for bandwidth usage, which should not be affected by cleaning up stemcells or not.
Given the above calculations, I would advocate for simplifying the policy to 3 years for all stemcells (heavy, light, windows).
1,8k per year compared to the current 40k a year would be a great improvement.

I think that it makes sense to announce this change in the community and define a date when it will be implemented so that users requiring older versions of the  stamecells have also as option to download them before they get removed.

Have updated the proposal with 3 years retention for all stemcells + cleanup of unpublished candidate stemcells after 2 months.

https://github.com/orgs/cloudfoundry/teams/toc called for and approved the Final Comment Period for this RFC, so it is now open for final commentary until next Tuesday, July 5th.

authors: LeePorte beyhan jimconner norman-abramovitz nouseforaname pburkholder ramonskie rkoster

repo: cloudfoundry/community


text:
Only enable PSRemoting if not already

Allows setup.ps1 to be run via WinRM without resetting the connection because of a forced WinRM service restart.
Should be slightly faster for systems that already have WinRM enabled.
Allows advanced users to enable WSMan endpoints for DSC without enabling PSRemoting if desired.

Merged as 92e33bd2a8cc262845e843403372676d00953a61. Thanks!

authors: mhoran sneal

repo: cloudfoundry/garden-windows-release


text:
Restructure go packages

✅  https://github.com/cloudfoundry/stembuild/pull/36 is merged

@aramprice , could you add a bit of context on the restructuring?

@jpalermo - added context to the description

authors: aramprice jpalermo

repo: cloudfoundry/stembuild


text:
add a class_name to CurveMesh3D so it can be made and used in scripts

I am publishing my first addon and am having to use a slightly modified version of your addon so that I can embed your class in my scripts.
a simple class_name at the top of curvemesh3d.gd would be all thats needed to make use of this in scripts

Hi @walksanatora , thank you for your interest in my add-on!
I've updated the code to include class_name CurveMesh3D at the top, which should make it easier to integrate the class directly in your scripts. This change is non-breaking, so it should be smooth to update. Let me know if it works well for you!
In case you need a workaround in the future, here are a couple of alternative ways to use a script without class_name:

Define a constant: Add the following at the beginning of your script to preload the class:
const CurveMesh3D = preload("res://addons/curvemesh3d/curvemesh3d.gd")
# ...
var my_instance = CurveMesh3D.new()

Inherit directly by path: If you’re inheriting, you can specify the path in the extends statement:
extends "res://addons/curvemesh3d/curvemesh3d.gd"

Good luck with your add-on!
Best,
C.

authors: cloudofoz walksanatora

repo: cloudofoz/godot-curvemesh

license: MIT


text:
Tf14 dependency fix

what

Update S3 log storage dependency for 0.14 readiness.
workflows updated

why

Module is not 0.14 ready yet

supersedes and closes #33

/test all

/test all


text:
Add variables to specify data types for Hash and Range keys

what

Add variables to specify data types for Hash and Range keys

why

The primary keys (Hash and Range) can accept 3 data types: String, Number & Binary
Closes #24

references

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html

Thank you @aknysh for addressing this issue :+1:
I have one question regarding the implementation of dynamo attributes. Why are we not passing hash and range key directly to the variable dynamodb_attributes? There will be 2 advantages to that:

We won't be requiring the variables hash_key_type and range_key_type.
The following code will become redundant
https://github.com/cloudposse/terraform-aws-dynamodb/blob/d88edcd98ed2fe8f021116098a747b98eced8c60/main.tf#L10-L30

I'm not sure why this certain approach was taken, maybe I have missed something out. Again, thanks for your help.

@sahil21  thanks again!
I think it was done from the beginning because we still need to provide hash and range keys here
https://github.com/cloudposse/terraform-aws-dynamodb/blob/master/main.tf#L53
so we'd have to specify it two times, in the input vars and in the attributes var.
That probably could be revisited and improved.
We can address it little bit later.
If you know how to do it better, PRs are welcome!
thanks

@aknysh Thanks for the explanation. I'll try to raise a PR soon over the weekend.

repo: cloudposse/terraform-aws-dynamodb


text:
Add additional inputs

What

Utilize all aws_instance attributes and arguments

Why

In order to have the ability to add additional inputs

has been tested
module "admin_tier" {
  source                      = "../terraform-aws-ec2-instance"
  ssh_key_pair                = "sweetops"
  github_api_token            = ""
  github_organization         = ""
  github_team                 = ""
  vpc_id                      = "some_id"
  security_groups             = ["some_id"]
  subnet                      = "some_id"
  associate_public_ip_address = "true"
  name                        = "kafka"
  namespace                   = "cp"
  stage                       = "dev"
  additional_ips_count        = "1"
  ebs_volume_count            = "2"
}

Can confirm that user_data works properly, instance is available.

EBS attachment works

Additional EIPs work

But interface configuration should be added manually

authors: SweetOps comeanother s2504s


text:
S3deeparchive support

Support transition to the deep archive storage class
We need this for our business.

/test all

/test all

authors: bcoddens maximmi


text:
UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v2.6.30 to before v5.12.13",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bdbe6fbc6a2f2ccfb384b141b257677d2a8d36fb",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b25b60d076164edb3025e85aabd2cf50a5215b91"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "bdbe6fbc6a2f2ccfb384b141b257677d2a8d36fb",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "b25b60d076164edb3025e85aabd2cf50a5215b91",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "net: rds: fix memory leak in rds_recvmsg\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.12.13 by commit b25b60d076164edb3025e85aabd2cf50a5215b91, it was introduced in version v2.6.30 by commit bdbe6fbc6a2f2ccfb384b141b257677d2a8d36fb. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1001056

repo: cloudsecurityalliance/security-database


text:
UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.10 to before v5.15",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=918698d5c2b50433714d2042f55b55b090faa167",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f4e54bd312d3dafb59daf2b97ffa08abebe60f5"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "918698d5c2b50433714d2042f55b55b090faa167",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "3f4e54bd312d3dafb59daf2b97ffa08abebe60f5",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "drm/amdgpu: Fix even more out of bound writes from debugfs\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15 by commit 3f4e54bd312d3dafb59daf2b97ffa08abebe60f5, it was introduced in version v5.10 by commit 918698d5c2b50433714d2042f55b55b090faa167. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1002196

repo: cloudsecurityalliance/uvi-database


text:
Fix false positive on aws_s3_bucket.bucket_prefix

Q
A

🐛 Bug fix?
yes

🚀 New feature?
no

⚠ Deprecations?
no

❌ BC Break
no

🔗 Related issues
#614

❓ Documentation
no

Description
This PR closes #614 by ignoring bucket_prefix attribute of aws_s3_bucket as it is an internal Terraform property.
The change is trivial and I've tested it in my AWS account, but I can probably add unit tests if needed.

Thanks a lot for this one !
@all-contributors can you add @a-vorobiev to bug

authors: a-vorobiev eliecharra

repo: cloudskiff/driftctl


text:
feat: Take into account number of databases in an instance

Instances configured with <1000 PUs only support 10 DBs per 100 PUs so clamp the minimum size to the relevant number of PUs
Fixes #286

/gcbrun

Thanks!

repo: cloudspannerecosystem/autoscaler

license_source: bigquery


text:
Add to the Grafana.net plugin repo

https://github.com/grafana/grafana-plugin-repository

PR created

It got merged

repo: cloudspout/cloudspout-button-panel


text:
docs: add warming up for kitex

What type of PR is this?
docs: Documentation only changes
Check the PR title.

[X] This PR title match the format: <type>(optional scope): <description>
[X] The description of this PR title is user-oriented and clear enough for others to understand.

(Optional) Translate the PR title into Chinese.
(Optional) More detailed description for this PR(en: English/zh: Chinese).
en:
zh(optional):
(Optional) Which issue(s) this PR fixes:

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


text:
Question: Can you add api.proto to hz new?

Is your feature request related to a problem? Please describe.
在 hz 使用 proto 生成代码时, 每次都要从文档中复制 api.proto, 我觉得可以在 hz new 时生成一个, 不使用可以自行删除
Describe the solution you'd like
能否在 hz new 时增加 api.proto
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

这个不是 Question @Skyenought 另外这个有实际的用户场景&诉求嘛

authors: Skyenought li-jin-gou

repo: cloudwego/hertz


text:
线程权重等于0时，一次性要把队列所有消息处理完毕？

for (i=0;i<n;i++) { 		if (skynet_mq_pop(q,&msg)) { 			skynet_context_release(ctx); 			return skynet_globalmq_pop(); 		} else if (i==0 && weight >= 0) { 			n = skynet_mq_length(q); 			n >>= weight; 		}
消息处理的源代码，这里如果线程权重为0，岂不是要把队列里所有消息一次性处理完毕？是BUG吗？

权重那么高难道不需要及时处理掉？
发自我的 iPhone

在 2017年11月17日，19:35，roc notifications@github.com 写道：
for (i=0;i<n;i++) { if (skynet_mq_pop(q,&msg)) { skynet_context_release(ctx); return skynet_globalmq_pop(); } else if (i==0 && weight >= 0) { n = skynet_mq_length(q); n >>= weight; }
消息处理的源代码，这里如果线程权重为0，岂不是要把队列里所有消息一次性处理完毕？是BUG吗？
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

已经看到了之前类似的issue，得到了答案，关闭了

authors: Yoodaa zhulu-mike

repo: cloudwu/skynet


text:
Update circe-core, circe-generic, ... to 0.14.5

Updates

io.circe:circe-core
io.circe:circe-generic
io.circe:circe-parser

from 0.13.0 to 0.14.5.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.circe" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.circe" }
}]

labels: library-update, early-semver-major, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #671.


text:
BioNLPProcessor now inherits from FastNLPProcessor

BioNLPProcessor now extends FastNLPProcessor instead of CoreNLProcessor.  FastNLPProcessoruses a parsing model that is both faster and performs ~12 pts (F1) better thanCoreNLPProcessor` the on GENIA test data (performance on the GENIA corpus was measured and reported by @terroni).

have you tried running the reach tests with this?

No.  There are two failing tests anyway, so I guess I will have to do some spelunking.

@MihaiSurdeanu, I've fixed the failing tests in processors.  The bad news is that when I ran the reach tests with this change, over 30 tests fail.
One thing I've noticed after comparing parses is that with the switch to the FastNLPProcessor parser in BioNLPProcessor, we're now finding (many) prepositional clausal modifiers (prepc_).
There are 31 tests in reach/main (run via sbt main/test), 2 in reach/assembly (run via sbt causalAssembly/test), and 1 in reach/export (run via sbt export/test).   In some cases we're finding additional mentions, while in others we're finding fewer than expected (usually none).
It will require some effort to fix these issues, but it is hard to estimate how much.   For example, we will need to adjust the rules to allow for clausal modifiers (ex. selectively replacing /prep_/ with /prepc?_/).

Thanks!
Hmm… This makes me wonder if we should just bite the bullet and switch to universal dependencies...
On Dec 13, 2016, 11:14 PM -0700, Gus Hahn-Powell notifications@github.com, wrote:

@MihaiSurdeanu, I've fixed the failing tests in processors. The bad news is that when I ran the reach tests with this change, over 30 tests fail.
One thing I've noticed after comparing parses is that with the switch to the FastNLPProcessor parser in BioNLPProcessor, we're now finding (many) prepositional clausal modifiers (prepc_).
There are 31 tests in reach/main (run via sbt main/test), 2 in reach/assembly (run via sbt causalAssembly/test), and 1 in reach/export (run via sbt export/test). In some cases we're finding additional mentions, while in others we're finding fewer than expected (usually none).
It will require some effort to fix these issues, but it is hard to estimate how much. For example, we will need to adjust the rules to allow for clausal modifiers (ex. selectively replacing /prep_/ with /prepc?_/).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

authors: MihaiSurdeanu myedibleenso

repo: clulab/processors


text:
cherry-pick and merge oauth2 progress from ynqa

Compiles, but crashes on the clusters I have with third party providers, so will have to visit it later. Help would be appreciated here.
See #19 for discussion.

Just wanted to comment that the other changes in this PR work quite nicely on my AWS EKS clusters.
I was able to run the pod_reflector example and get a list of all my pods with a kubeconfig similar to the one below.
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCk1JSUNxRENDQVpBQ0FRQXdZekVMTUFrR0ExVUVCaE1DVUV3eEVEQU9CZ05WQkFNTUIyWnZieTVpWVhJeER6QU4KQmdOVkJBY01CbXhyYW5Oa1pqRVBNQTBHQTFVRUNnd0dhMnhyYW1aek1ROHdEUVlEVlFRSURBWnNhMnB6WkdZeApEekFOQmdOVkJBc01CbXhyYW5Oa1pqQ0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCCkFMOHdOMEM2NncwUnAwQkxVN2lRYWVUZHZMSDVwWGF3OEJDZjdyYzVKK2VqS3Q5R21FS1Q5a0RjeVEvY0xTL3QKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ==
    server: https://A736D1E5D65102DE509F10BF9582447C.yl4.us-east-1.eks.amazonaws.com
  name: arn:aws:eks:us-east-1:0123456789012:cluster/my-cluster
contexts:
- context:
    cluster: arn:aws:eks:us-east-1:0123456789012:cluster/my-cluster
    user: arn:aws:eks:us-east-1:0123456789012:cluster/my-cluster
  name: my-ctx
current-context: my-ctx
kind: Config
preferences: {}
users:
- name: arn:aws:eks:us-east-1:0123456789012:cluster/my-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws
      args:
      - --region
      - us-east-1
      - eks
      - get-token
      - --cluster-name
      - my-cluster
      - --role
      - arn:aws:iam::0123456789012:role/my-role

That's really helpful. Thanks a lot. I'll probably just speculatively merge this branch then for the next release.

I've managed to make this branch compile with up to date master by doing a bunch of manual Error conversions. Will try to improve it later.
In the mean time, any chance you could see if this branch still works for you on EKS @stephenmuss ?
[dependencies]
kube = { git = "https://github.com/clux/kube-rs", rev = "8b7a0b832b04965027a639010c420bd2cc3a5bfa" }

The branch doesn't work for me after the merge.
I get the following errors with the node_reflector and pod_reflector.
$ cargo run --example node_reflector
   Compiling kube v0.12.0 (/Users/steve/code/rs/kube-rs)
error[E0599]: no function or associated item named `v1Node` found for type `kube::api::typed::Api<_>` in the current scope
  --> examples/node_reflector.rs:14:25
   |
14 |     let resource = Api::v1Node(client);
   |                         ^^^^^^ function or associated item not found in `kube::api::typed::Api<_>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: Could not compile `kube`.

To learn more, run the command again with --verbose.

$ cargo run --example pod_reflector
   Compiling kube v0.12.0 (/Users/steve/code/rs/kube-rs)
error[E0599]: no function or associated item named `v1Pod` found for type `kube::api::typed::Api<_>` in the current scope
  --> examples/pod_reflector.rs:14:25
   |
14 |     let resource = Api::v1Pod(client).within(&namespace);
   |                         ^^^^^ function or associated item not found in `kube::api::typed::Api<_>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: Could not compile `kube`.

To learn more, run the command again with --verbose.

With an empty cargo project I also get an error with just this in Cargo.toml
[dependencies]
kube = { git = "https://github.com/clux/kube-rs", rev = "8b7a0b832b04965027a639010c420bd2cc3a5bfa" }

Compiling kube v0.12.0 (https://github.com/clux/kube-rs?rev=8b7a0b832b04965027a639010c420bd2cc3a5bfa#8b7a0b83)
error[E0277]: the trait bound `chrono::datetime::DateTime<chrono::offset::utc::Utc>: _IMPL_SERIALIZE_FOR_ApiError::_serde::Serialize` is not satisfied
  --> /Users/steve/.cargo/git/checkouts/kube-rs-7892a19212f788e8/8b7a0b8/src/config/exec.rs:26:5
   |
26 |     #[serde(rename = "expirationTimestamp")]
   |     ^ the trait `_IMPL_SERIALIZE_FOR_ApiError::_serde::Serialize` is not implemented for `chrono::datetime::DateTime<chrono::offset::utc::Utc>`
   |
   = note: required because of the requirements on the impl of `_IMPL_SERIALIZE_FOR_ApiError::_serde::Serialize` for `std::option::Option<chrono::datetime::DateTime<chrono::offset::utc::Utc>>`
   = note: required by `_IMPL_SERIALIZE_FOR_ApiError::_serde::ser::SerializeStruct::serialize_field`

error[E0277]: the trait bound `chrono::datetime::DateTime<chrono::offset::utc::Utc>: _IMPL_SERIALIZE_FOR_ApiError::_serde::Deserialize<'_>` is not satisfied
  --> /Users/steve/.cargo/git/checkouts/kube-rs-7892a19212f788e8/8b7a0b8/src/config/exec.rs:26:5
   |
26 |     #[serde(rename = "expirationTimestamp")]
   |     ^ the trait `_IMPL_SERIALIZE_FOR_ApiError::_serde::Deserialize<'_>` is not implemented for `chrono::datetime::DateTime<chrono::offset::utc::Utc>`
   |
   = note: required because of the requirements on the impl of `_IMPL_SERIALIZE_FOR_ApiError::_serde::Deserialize<'_>` for `std::option::Option<chrono::datetime::DateTime<chrono::offset::utc::Utc>>`
   = note: required by `_IMPL_SERIALIZE_FOR_ApiError::_serde::de::SeqAccess::next_element`

error[E0277]: the trait bound `chrono::datetime::DateTime<chrono::offset::utc::Utc>: _IMPL_SERIALIZE_FOR_ApiError::_serde::Deserialize<'_>` is not satisfied
  --> /Users/steve/.cargo/git/checkouts/kube-rs-7892a19212f788e8/8b7a0b8/src/config/exec.rs:26:5
   |
26 |     #[serde(rename = "expirationTimestamp")]
   |     ^ the trait `_IMPL_SERIALIZE_FOR_ApiError::_serde::Deserialize<'_>` is not implemented for `chrono::datetime::DateTime<chrono::offset::utc::Utc>`
   |
   = note: required because of the requirements on the impl of `_IMPL_SERIALIZE_FOR_ApiError::_serde::Deserialize<'_>` for `std::option::Option<chrono::datetime::DateTime<chrono::offset::utc::Utc>>`
   = note: required by `_IMPL_SERIALIZE_FOR_ApiError::_serde::de::MapAccess::next_value`

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0277`.
error: Could not compile `kube`.

To learn more, run the command again with --verbose.

I think that's just the missing feature. How about:
[dependencies]
kube = { git = "https://github.com/clux/kube-rs", rev = "8b7a0b832b04965027a639010c420bd2cc3a5bfa", features = ["openapi"] }
k8s-openapi = { version = "0.4.0", features = ["v1_13"] }

:+1: Yep, that did the trick.
Examples work and new cargo project looks good too.

Awesome. Thanks a lot. I'll clean up a few unrelated things and try to merge this ASAP.

Released in kube 0.13.0

authors: clux stephenmuss

repo: clux/kube-rs


text:
try out kubernetes orb - for #252

heavy WIP, using another image i have available rather than an in source thing.
plan:

[x] make a TINY example (no actix)
[x] compile it
[x] stuff it into a tiny image
[x] boot a kind/minikube cluster (using kind)
[x] use kubernetes orb to apply the resources
[x] ensure it succeeds

Pretty happy with this now:


text:
Play with multiple user tables/models

Hi, in my website there are two different kinds of users(multi auth), let's say "student" and "consultant" instead of one kind of "user".
According to the discussion in another issue, an easy approach is to modify the config file, but I guess if I hack like
'user_model' => App\Student::class || App\Consultant::class,
obviously it won't work.. so how should I modify it?
PS: I use Auth::user("Student") or Auth::user("Consultant") in controllers and elsewhere, does it help?
PPS: @a-komarev mentioned that extending Thread.php, but since Student and Consultant both have a unique ID and they can talk to each other, is that necessary for me?
Many thanks!

I'm also facing the same issue.
Thanks for bringing this up :)

All these users are in one table? If so - you can easily display different views for different groups by getting user type (role, or group) as you named it.

If you have many types of users which not sharing the same ID you can overwrite package models and add polymorphic relation instead single user.

The only way that I can see this happening is if you do what @a-komarev mentioned - overwriting package models and adding some additional relationships.
Right now I don't think handling multiple "user" models should be in the package since it's not aligned to how Laravel treats users. I'm going to close this for now, but feel free to keep the conversation going if needed.

authors: a-komarev cmgmyr sellegabuya xuan9230

repo: cmgmyr/laravel-messenger

license: mit


text:
Linux packages

Closes #41.

Codecov Report

Merging #47 (a890b6d) into main (629a2ad) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #47   +/-   ##
=======================================
  Coverage   94.89%   94.89%
=======================================
  Files          10       10
  Lines        1429     1429
=======================================
  Hits         1356     1356
  Misses         73       73

Flag
Coverage Δ

unittests
94.89% <ø> (ø)

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

Continue to review full report at Codecov.

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

authors: cmmorrow codecov-commenter

repo: cmmorrow/build-magic


text:
Different results with each run

As Pointed out by @adavidzh , when running HybridNew with the same (default) seed, the limit is different. The RooFit seed is set but not clear that ROOT gRandom is.
Possibly related to this line
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/blob/ec31c309bcd95f4c116ad6f3faf8018908f1fa8d/src/HybridNew.cc#L1682
Does anyone know (maybe @guitargeek ?) If this coukd be the cause and how to resolve it?

Hi, from the top of my head  I have no idea. How can this be reproduced? Then I can help figuring out what's going on

Running the following will show the behaviour
combine template-analysis-datacard.txt -M HybridNew --LHCmode LHC-limits --rMax 2.0 --clsAcc 0.01
The datacard can be found in
data/tutorials/CAT23001/template-analysis-datacard.txt
On Sat, 16 Dec 2023, 18:10 Jonas Rembser, @.***> wrote:

Hi, from the top of my head I have no idea. How can this be reproduced?
Then I can help figuring out what's going on
—
Reply to this email directly, view it on GitHub
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/issues/883#issuecomment-1858893730,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMEVWZJLNPUJQE7KCQESR3YJXP2NAVCNFSM6AAAAABAXQYKTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJYHA4TGNZTGA
.
You are receiving this because you authored the thread.Message ID:
@.***
com>

Running the following will show the behaviour
combine template-analysis-datacard.txt -M HybridNew --LHCmode LHC-limits
--rMax 2.0 --clsAcc 0.01

The datacard can be found in
data/tutorials/CAT23001/template-analysis-datacard.txt

Some updates. It seems to be related to the "on the fly" workspace creation. If one first creates the binary workspace and uses that as input, then the repeated runs produces the same output eg.
With the text file directly
combine template-analysis-datacard.txt -M HybridNew --LHCmode LHC-limits --rMax 2.0 --clsAcc 0.01
 -- Hybrid New --
Limit: r < 0.335698 +/- 0.0143468 @ 95% CL
Done in 0.15 min (cpu), 0.15 min (real)

combine template-analysis-datacard.txt -M HybridNew --LHCmode LHC-limits --rMax 2.0 --clsAcc 0.01
 -- Hybrid New --
Limit: r < 0.356193 +/- 0.0349485 @ 95% CL
Done in 0.18 min (cpu), 0.18 min (real)

first building the workspace
text2workspace.py template-analysis-datacard.txt

combine template-analysis-datacard.root -M HybridNew --LHCmode LHC-limits --rMax 2.0 --clsAcc 0.01
 -- Hybrid New --
Limit: r < 0.346362 +/- 0.0134581 @ 95% CL
Done in 0.24 min (cpu), 0.25 min (real)

combine template-analysis-datacard.root -M HybridNew --LHCmode LHC-limits --rMax 2.0 --clsAcc 0.01
 -- Hybrid New --
Limit: r < 0.346362 +/- 0.0134581 @ 95% CL
Done in 0.24 min (cpu), 0.24 min (real)

Could the binary file creation have something to do with it?

Digging a bit more, it seems like this might be intentional. In these lines https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/blob/ec31c309bcd95f4c116ad6f3faf8018908f1fa8d/src/Combine.cc#L311-L322 ,  a temporary file is created to store the workspace if the input is the datacard. This allows one to run multiple commands in parallel without worrying about each one writing over eachother.
However, this c++ method cannot be seeded for reproducibility and since it seems RooFits random number generator is tied to TRandom (which in turn is tied to this one - is that right @guitargeek ?), we can't avoid non-reproducible results if one runs the same command over and over on the .txt file.
@adavidzh , I think we just need to make it clear to a user that if they run the commands that use toys, they will get different but consistent results each time unless they first convert to a binary file and use that as the input.

a temporary file is created to store the workspace if the input is the datacard. This allows one to run multiple commands in parallel without worrying about each one writing over eachother.

I would argue that we should be able to create a unique - per job - deterministic identifier. I.e., we do not need a random thing, just a unique one, that can e.g., be made out of a hash of things like the datacard and command line options.

To be clear,
As far as I can tell this is done by ROOT rather than something we can
control. Perhaps Someone more expert in the inner workings of root can see
if it can be bypassed
On Sun, 24 Dec 2023, 16:47 André David, @.***> wrote:

a temporary file is created to store the workspace if the input is the
datacard. This allows one to run multiple commands in parallel without
worrying about each one writing over eachother.
I would argue that we should be able to create a unique - per job -
deterministic identifier. I.e., we do not need a random thing, just a
unique one, that can e.g., be made out of a hash of things like the
datacard and command line options.
—
Reply to this email directly, view it on GitHub
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/issues/883#issuecomment-1868556397,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMEVW4MY6EHAEC3JRDSKJ3YLBMC3AVCNFSM6AAAAABAXQYKTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGU2TMMZZG4
.
You are receiving this because you authored the thread.Message ID:
@.***
com>

Hint @guitargeek 😉

I don't get it @nucleosynthesis: the code you reference (with mkdtemp and mkstemp) is combine's.

Right,
https://man7.org/linux/man-pages/man3/mkstemp.3.html
https://man7.org/linux/man-pages/man3/mkdtemp.3.html
Are what we use to guarantee to uniqueness but it seems that uses the same seed that RooFit will then use.
Using the same datacard and command would imply the same hash so not sure that would work with concurrent identical command lines (which we can't do currently)
Too much of this is my own speculation (based on some minimal testing) though, so perhaps there is simply a way to avoid the clash between the seed that RooFit uses and the one being triggered by the call to mkstemp.

Just for completeness, I don't think this is limited to toy-based methods like HybridNew. I see the same effect (slightly different numerical values) when running the asymptotic Significance method from the datacards, but if I produce the workspace first and rerun the results are identical.  Still, negligibly small differences, but it appears to be the same issue.

authors: adavidzh guitargeek kcormi nucleosynthesis


text:
Load jhu-csse backfilled data

Currently, the jhu-csse pipeline derives its daily incidence and cumulative by reading from the confirmed_US and deaths_US sheets here:
https://github.com/CSSEGISandData/COVID-19/tree/master/csse_covid_19_data/csse_covid_19_time_series
(Note that daily reports are also available, but they do not stretch very far in time for the United States).
I recently learned that JHU backfills its US data: https://github.com/CSSEGISandData/COVID-19/blob/master/csse_covid_19_data/csse_covid_19_time_series/Errata.csv
The number of changes to the US data are sufficiently small that ignoring them probably would not be much worse than rounding error; but in principle we should probably incorporate them.

Hi all - I'd like to mention that this issue remains a major factor in our project at the COVID Forecast Hub not being able to more fully incorporate covidcast into our everyday pipeline. We have had to essentially duplicate covidcast functionality to provide our own versions of the JHU-CSSE dataset. This is crazy because you all have such polished functionality for this, but in order to make the switch to adopting covidcast, we need full backfilled data for jhu-csse to be available. Any updates on when this might be solved?

We're currently repairing major issues in the JHU indicator. Once we have basic JHU functionality back online, we'll be able to pursue this item with greater focus.
In the meantime, work on integrating backfill is proceeding in parallel. Unfortunately, as you are probably aware, JHU has changed its geo coding several times since the beginning of the pandemic, and the git history includes several errors introduced by hand-edits. Both factors make it difficult for an automatic exporter to parse the data history. If your team has solved any these problems, we'd be eager to swap notes -- let me know.

From our perspective, we want the data as JHU had reported it at a given moment in time. we'd want the data exactly as JHU released it, so in some senses we want it NOT cleaned up. we want the data as models would have seen it "as of" a particular time, funny geo-codings and all.
It strikes me that we have only been using the US data from JHU and I haven't been aware of major changes in the geocoding there. (we haven't run into any issues like this yet that I am aware of.) Maybe starting with the US data would be a place to split this into a few separate tasks?

The US data is indeed where we've run into geocoding issues with JHU, such as their switch in handling of New York City. We haven't worked with their international data at all yet.

I see what you mean. I think that's just how the data is. it's a feature, not a bug to be corrected. E.g. if we want covidcast to be a faithful representation of what JHU was showing at a given time (that's what we use it for when modeling retrospectively) then you all in the DELPHI group shouldn't be changing the FIPS codes that are in the JHU data. you are just mirroring what they had. Is it perfect, no? should you maybe make a separate "clean" JHU signal that tries to address these issues, maybe? but as a first pass, just mirroring this imperfect data would be very helpful for us at the COVID Forecast Hub (and for all the modeling teams that are contributing)!

it's a feature, not a bug to be corrected.

The kinds of errors I'm talking about are the accidental deletion of commas and other formatting errors that invalidate the whole file. Not sure what the right call is there other than skipping those versions entirely.

That seems reasonable to me, to just skip the version entirely.

but the changes in geocoding issues should not block this from being updated, imho.

@eujing, @dshemetov , and I looked into this yesterday. Looks like the files which were available on each day by 10AM ET could all be parsed and did not contain nan values, so we can probably backfill them without issues. Working with @eujing right now on that.

authors: capnrefsmmat chinandrew huisaddison krivard nickreich

repo: cmu-delphi/covidcast-indicators


text:
feat: Add elastic ip for Grafana

What type of PR is this?
kind/feature
What this PR does / why we need it:
This creates an Equinix elastic IP named monitoring and assigns it to the node where Grafana is deployed.
This will allow us to request a DNS record for green-reviews.tag-env-sustainability.cncf.io
Which issue(s) this PR fixes:
Towards https://github.com/cncf-tags/green-reviews-tooling/issues/31
Special notes for your reviewer (optional):

Elastic IPs are not automatically added so this is done using netplan since the machines run Ubuntu
https://deploy.equinix.com/developers/docs/metal/networking/elastic-ips/#host-ip-configuration
The elastic IP is also configured with K3s by setting the --node-external-ip flag
https://docs.k3s.io/cli/agent#networking
With this Grafana is accessible in my test cluster at the external IP

k get no -o wide
NAME                              STATUS   ROLES                  AGE   VERSION        INTERNAL-IP     EXTERNAL-IP     OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
green-reviews-worker-falco-a      Ready    <none>                 26m   v1.29.0+k3s1   147.28.133.63   <none>          Ubuntu 22.04.4 LTS   5.15.0-94-generic   containerd://1.7.11-k3s2
green-reviews-worker-internal-1   Ready    <none>                 25m   v1.29.0+k3s1   147.28.134.59   147.28.133.50   Ubuntu 22.04.4 LTS   5.15.0-94-generic   containerd://1.7.11-k3s2
green-reviews-control-plane       Ready    control-plane,master   28m   v1.29.0+k3s1   147.28.134.47   <none>          Ubuntu 22.04.4 LTS   5.15.0-94-generic   containerd://1.7.11-k3s2

@nikimanoledaki @AntonioDiTuri Like we discussed I've updated to use a global IP for the elastic IP. In case we want to move region for the cluster for #4

Feel free to merge whenever

repo: cncf-tags/green-reviews-tooling


text:
Taylorwaggoner new members

Pre-submission checklist:
Please check each of these after submitting your pull request:

[x] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[x] Is your project closed source or, if it is open source, does your project have at least 250 GitHub stars?
[x] Have you picked the single best (existing) category for your project?
[x] Does it follow the other guidelines from the new entries section?
[x] Have you included a URL for your SVG or added it to hosted_logos and referenced it there?
[x] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[x] Does your project/product name match the text on the logo?
[x] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~5 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

Deploy preview for landscape failed.
Built with commit 431da012ddb8b697d97afeda5580806f1ac52679
https://app.netlify.com/sites/landscape/deploys/5d291934a7fc6800091be90f

LGTM

authors: CNCF-Bot taylorwaggoner

repo: cncf/landscape


text:
Adding Silver Members

Pre-submission checklist:
Please check each of these after submitting your pull request:

[ ] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[ ] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[ ] Have you picked the single best (existing) category for your project?
[ ] Does it follow the other guidelines from the new entries section?
[ ] Have you added your SVG to hosted_logos and referenced it there?
[ ] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[ ] Does your project/product name match the text on the logo?
[ ] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~15 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

Build failed because of:
No cached entry, and GitLab Hubei (member) has issues with logo: gitlabhubei.svg, ENOENT: no such file or directory, open '/opt/build/repo/hosted_logos/gitlabhubei.svg'
Empty twitter for Rancher Federal (member): https://twitter.com/rancherfederal
No cached entry, and Valve Software (member) has issues with twitter: https://twitter.com/valveoficial, 404 - {"errors":[{"code":34,"message":"Sorry, that page does not exist."}]}
No cached entry, and Sosivio (member) has issues with twitter: https://twitter.com/SosivioLtd, 404 - {"errors":[{"code":34,"message":"Sorry, that page does not exist."}]}
No cached entry, and Kingsoft (member) has issues with twitter: https://twitter.com/KingsoftC, 401 - {"request":"/1.1/statuses/user_timeline","error":"Not authorized."}
No cached entry, and Kingsoft Cloud (KCSP) has issues with twitter: https://twitter.com/KingsoftC, 401 - {"request":"/1.1/statuses/user_timeline","error":"Not authorized."}
No cached entry, and Kingsoft Cloud has issues with twitter: https://twitter.com/KingsoftC, 401 - {"request":"/1.1/statuses/user_timeline","error":"Not authorized."}
Empty twitter for Standard Library: https://twitter.com/AutocodeHQ
Empty twitter for StackStorm: https://twitter.com/Stack_Storm
Item GitLab Hubei (member) has no image_data

authors: CNCF-Bot ErinThacker


text:
[VOTE] Proposing Sarah Christoff as Tech Lead of the TAG App Delivery

Hey y'all,
Sarah has been going through a trial-run as tech lead for the past couple of months, and she has been doing a great job. I would like to propose that we vote for Sarah to officially get the role of tech lead.
Bio
Sarah Christoff is a software engineer at Defense Unicorns. She is a maintainer of Porter, a CNCF sandbox project, and leads the Zarf team which is donated to the OpenSSF. Sarah has been involved in TAG App Delivery as a member for the past year.
Action requested: This issue is to ask TAG App Delivery's leaders, TOC Liaisons, and WG Leads (@kgamanji, @linsun, @lianmakesthings, @thschue, @abangser, @sabre1041, @krumware, @rchincha, @salaboy, @danieloh30, @ThomasVitale) for their support in nominating her as tech lead. Please add a +1 to indicate your support. After the majority has agreed, I will forward the proposal to the TOC.

YESSSSS 👏  So excited for @schristoff to join the team officially! She's been doing a lot since coming on as TL "on probation". Super happy and grateful to have her ❤

+1 from my side and happy to have her in the boat!

Yes from me!

+1 for me too

Blog: http://salaboy.com http://salaboy.wordpress.com

Github user: http://github.com/salaboy

Twitter: http://twitter.com/salaboy

Mauricio "Salaboy" Salatino -

On Mon, 26 Aug 2024 at 17:19, Colin Griffin @.***>
wrote:

Yes from me!
—
Reply to this email directly, view it on GitHub
https://github.com/cncf/tag-app-delivery/issues/739#issuecomment-2310584054,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACCMXQWDO4XLRDDDERF57DZTNIQHAVCNFSM6AAAAABM4FPFOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQGU4DIMBVGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

+1 also for me

This was a joyful surprise seeing Sarah @schristoff being mentioned here, when I browse over the available issues on the TAG App Delivery.
I may neither have the voting rights to give +1 on this nor the most active member of the WG Platform and overall TAG as well, but I just want to give a shoutout on how I believe you folks will be lucky to have her as Tech Lead.
I contributed to Porter back then (which unfortunately for now have no such time commitment to do so 😞 ) when Carolyn was still the maintainer, and I can see that Sarah continue to bring the passed baton forward of the Porter impressively. We had a chat on Porter booth on KubeCon North America 2023 Chicago and her thoughtfulness is what would make her an indispensable member of any open source community, that's what we need more people to have.
So, fully rooting for Sarah! 💪

Closing this as the TOC vote was a success 🎉

authors: ThomasVitale joshuabezaleel krumware lianmakesthings roberthstrand salaboy thschue

repo: cncf/tag-app-delivery


text:
Each typed letter has "color:#000" and css is not working

I have the following inside a random component:
<script>
import { VueTyper } from "vue-typer";

export default {
  name: "WhyHow",
  components: {
    VueTyper,
  },
};
</script>

<template>
<div>
<vue-typer
  :text='["Arya Stark"]'
  :repeat='0'
  :shuffle='false'
  initial-action='typing'
  :pre-type-delay='70'
  :type-delay='70'
  :pre-erase-delay='2000'
  :erase-delay='250'
  erase-style='clear'
  :erase-on-complete='false'
  caret-animation='smooth'
></vue-typer>
</div>
</template>

<style scoped lang="css">
@keyframes rocking {
  0%,100% {transform: rotateZ(-10deg);},
  50%     {transform: rotateZ(10deg);}
}

.vue-typer {
  font-family: Arial, 'Helvetica Neue', Helvetica, sans-serif;
}
.vue-typer .custom.char.typed {
  color: #009688;
}
.vue-typer .custom.char.selected {
  color: #E91E63;
}

.vue-typer .custom.caret {
  animation: rocking 1s ease-in-out 0s infinite;
}
.vue-typer .custom.caret.typing {
  background-color: #009688;
}
.vue-typer .custom.caret.selecting {
  display: inline-block;
  background-color: #E91E63;
}
</style>

Yet, every span that gets created for each letter has color:#000.

I gather that this repo is not being watched anymore.
I'm still experiencing issues with this.
I cannot change the style at all.
I have tried:
  .vue-typer .custom.char.typed {
    color: #fff;
  }
::v-deep .typed {
  color: #fff;
}
/deep/ .typed {
  color: #fff;
}
>>> .typed {
  color: #fff;
}

And nothing renders the text white. NOTHING.
Sad to say, but this component is not working.

This is the solution I've found to work:
  ::v-deep .typed {
    color: #fff !important;
  }

That is the only thing that allowed me to set CSS rules to it.

Thanks @GeorgeFlorian, I was tearing my hair out with this one. It works for me too 🙏

This worked for me
::v-deep .vue-typer .custom.caret {   width: 3px;   margin-left: 2px;   background-color: #3f51b5; }

authors: GeorgeFlorian samdb sushil-kamble

repo: cngu/vue-typer


text:
Make default behavior for bootloader to enable LDOTRIM

Yuuki Umeta has had issues on a few boards not working reliably but on those boards, when we enabled LDOTRIM, the boards worked perfectly.
This is just changing that for the bootloader.  We can investigate other things later.

DON'T push it. I found out the another issue caused fixing LDOTRIM code.
First, I wrote "demo_hidapi" to new empty 100 boards without EXTEND->CTR |= EXTEN_LDO_TRIM;. Then, 2 boards had communication problems via "testtop". The remaining 98 boards worked fine.
Second, I wrote "demo_hidapi" to identical 100 boards with EXTEND->CTR |= EXTEN_LDO_TRIM;. Then 4 boards that aren't the first 2 bad had communication problems via "testtop". The remaining 96 boards worked fine.
In other words, depending on the EXTEND->CTR |= EXTEN_LDO_TRIM;, 100 boards can be classified into the following three patterns:

94 boards work fine with or without the fixing code.
2 boards work fine only with the fixing code.
4 boards work fine only without the fixing code.

This issue is reproducible on my PC. 2 and 4 bad boards were tried to switch the fixing code many times because it was unbelievable for me.

DON'T merge it. I found out the another issue caused fixing LDOTRIM code: EXTEND->CTR |= EXTEN_LDO_TRIM;
First, I wrote "demo_hidapi" to new empty 100 boards without the fixing code. Then, 2 boards had USB communication problems via "testtop". The remaining 98 boards worked fine.
Second, I wrote "demo_hidapi" to identical 100 boards with the fixing code. Then 4 boards that aren't the first 2 bad had USB communication problems via "testtop". The remaining 96 boards worked fine.
In other words, depending on the fixing code, 100 boards can be classified into the following three patterns:

94 boards work fine with or without the fixing code.
2 boards work fine only with the fixing code.
4 boards work fine only without the fixing code.

This issue is reproducible on my PC. 2 and 4 bad boards were tried to switch the fixing code many times because it was unbelievable for me.

The quantity, 2 or 4, is not important. In other words, it does not mean that I recommend you to adopt the code that will cause fewer issues. Because the number of surveyed cases is small, it is not correct to take this number as a probability.

holding off on merge

authors: YuukiUmeta-UIAP cnlohr


text:
Fantastic csv error message

github gets this one right - https://github.com/crbclean/leads/blob/8ea5f134dd0d63ef6d8eec17f4757b0c7b62b2b3/Alabama2.csv

Fixed this the old fashioned way - they are using escape characters to avoid quoting things like newlines.  escape is now an optional parameter that defaults to \.

repo: cnuernber/charred


text:
sql: disallow GRANT/REVOKE on system tables

PR: https://github.com/cockroachdb/cockroach/pull/61410
From release notes:

CockroachDB now disallows GRANT/REVOKE operations on system tables. [#61410][#61410] {% comment %}doc{% endcomment %}

Also cc @ericharmeling, who's been documenting internal tables.

repo: cockroachdb/docs


text:
sql/parser: grammar refactorings

PR: https://github.com/cockroachdb/cockroach/pull/17033

Covered by https://github.com/cockroachdb/docs/issues/1598


text:
Revert "Correct managed home page title"

Reverts cockroachdb/docs#3956

This change is

LGTM

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/df9a410c3bcb4727aa3e403480152b0d071edb19/

authors: benesch cockroach-teamcity jseldess


text:
getBucketIndex calculates index wrong, overflows on small values

There is an error in the following code
pow2Ceiling := bitLen(v | h.subBucketMask)
Leading zero base is missing. In this case it is constant 64
pow2Ceiling := 64 - bitLen(v | h.subBucketMask)

I’d happily merge a pull request, but I don’t have time to investigate this myself.

Currently, I don't have a time to investigate it either.

Sorry, I was wrong.
Reference implementation uses clz while go uses 'bitLen'. That's where difference is.

authors: aka-rider codahale

repo: codahale/hdrhistogram


text:
Point to correct setup instructions

Closes #13

Changed the link text to make it more descriptive. Also suggest we don't merge this PR until all changes to preparation.md are in place.

Hi @henryiii @srlantz  It's probably too late now, but let's still merge this. Maybe we can call out to the participants in the intro that they should follow the gcc setup instructions at least

authors: klieret srlantz


text:
CS0051 code fix

Fixes #321
Code fix for CS0051 and also initial structure for other errors related with inconsistent accessibility.
InconsistentAccesibilityProviders should return InconsistentAccessibilityInfo with TypeSyntax, new accessibility modifiers and code action message. With that information code fix is able to search type symbol, locate proper document in solution and change accessibility modifiers for that type.
@giggio, let  me know what do you think

@baks The type has to exist on the solution, otherwise you couldn't even be referencing it, right? For example:
File Person.cs in your solution:
class Person
{
    void WalkTheDog(Dog dog)
    {
    }
}

File Dog.cs outside of your solution, coming to you as a reference from a dll:
class Dog
{
}

This will actually raise CS0122, not CS0051.
This scenario would work even on the same solution, with files being on different projects.
I guess CS0051 is only raised when a method can reference the type, but not expose it outside as a parameter. If the type cannot be referenced, then we get CS0122.
BTW, if you can rebase or merge the changes from master it would be great. I updated some testing infrastructure.

Ok, I'll merge with master.
@giggio, If you create class like that in other assembly:
public class Dog
{
    protected class Walker
    {
    }
}

and you use it in your solution:
public class EnhancedDog
{
    public EnhancedDog(Walker walker)
    {
    }
}

This will raise CS0051.
Or if you use InternalsVisibleToAssembly() in example that you provided it should also raise CS0051 (I'm not sure about this on 100% percent, but I'll check this when I get home).

Hm... you are right!
We do need that check, then. If you can move all the other code to the other methods, away from RegisterCodeFixesAsync method, it would be fine.

BTW, another possible code fix would be to make the EnhancedDog constructor protected, right? Let's finish this one, then we can think about it later.

@giggio , exactly :+1:
This is the same as other fix I proposed in #321

@giggio I merged with master and included PR comments about RegisterCodeFixesAsync

@giggio , I changed code fix provider to handle partial classess and also changed extracting parameter type to be culture agnostic with a way that you provided

@baks The code is fine, but I found an inconsistent behavior on VS. I filed a bug here on the Roslyn repo: https://github.com/dotnet/roslyn/issues/3496
Because of that I think I will revert to a specific message until this is fixed. Tests pass but no code fix is offered at VS.

@baks See 9674315 where I updated the method.

authors: baks giggio

repo: code-cracker/code-cracker


text:
大大支持多微信吗

想同时跑多个微信

想同时跑多个微信

目前还不支持哪，但是可以自己魔改一下，非常简单就能支持跑多个微信

authors: Huboooo code-innovator-zyx

repo: code-innovator-zyx/wechat-gptbot


text:
微信小程序，有一定概率会 Undefined array key "session_key"

微信小程序，有一定概率会 Undefined array key "session_key"，code 100%获取

用的哪个版本？我这里一直没有出现你说的问题呀

authors: code-lives wongvio

repo: code-lives/Pays


text:
CreateProcess error=193, %1 is not a valid Win32 application

Hi,
I am getting an error Build failed: CreateProcess error=193, %1 is not a valid Win32 application.
Can u please help?
regards,
Himanshu

Hi Himanshi
I have no clue what this error message means. It sounds like you are using Windows?! Since I have no Windows OS here where I could test this I'm not able to help you. Sorry!
Best regards,
Thomas

authors: himanshudwivedi tbreuss

repo: code-smell/php-automate-build-ant


text:
Enhancement: Alignment Image colors with rest of UI color palette.

Currently in courses route for Folder, Video and Notes images have a very odd colors with rest of the UI color color palette.

Proposed Enhancement
Changing the images colors to align with the rest of UI

@hkirat attached zip file with all the images
images.zip

Is this task assigned to someone. Can I work on this. @hkirat sir.

authors: djbtw harpreet-deepdive


text:
Button styling is not applied in sent messages

Not every email clint supports CSS that is not inline

Local BrickHack issue.

Local BrickHack issue.

authors: cbaudouinjr peterkos

repo: codeRIT/hackathon-manager


text:
Say command inside some function crash the interpreter

i have a stupid problem with seperate the code into function.
here the POC of the bug
########
function test1(t){
t.say("test 1 here");
}
function test2(t){
t.say("test 2 here");
}
function callTest(t){
test2(t);
}
loop {
callTest(this);
}
########
if i remove the first say command "t.say("test 1 here"); "
the code works fine and i got my "test 2 here" message...! but why they do not accept a second say / function?!
thanks :)

Fixed with @basicer's new Esper interpreter.

repo: codecombat/codecombat


text:
Translate errors

Translates error messages via regex just before displaying them to the user. Also includes a page for checking how many of our common error messages are translated (which is a bit janky, but works)

Coverage remained the same at 18.112% when pulling 8299f1b4b8b127d3fe94cc5aff9098cd5e9babe5 on translate-errors into adcbbc7b5a396a2557f77520f30bf5590e1334ad on aetherize.

Coverage remained the same at 18.112% when pulling 17b3334d661939c11bd7db623461569c5d30279e on translate-errors into adcbbc7b5a396a2557f77520f30bf5590e1334ad on aetherize.

Coverage remained the same at 18.112% when pulling 746854a4ba672edf28ba8fcd8c34d244c73a76d5 on translate-errors into adcbbc7b5a396a2557f77520f30bf5590e1334ad on aetherize.

Coverage remained the same at 18.112% when pulling c037af68101d599d0c7b94cf0012b9f13adc5b32 on translate-errors into adcbbc7b5a396a2557f77520f30bf5590e1334ad on aetherize.

Coverage remained the same at 56.889% when pulling 264489334f18e01c003529457da649099d4dc641 on translate-errors into 4c99b4158f679eed727a1d2137ecc7471cd5e934 on aetherize.

Coverage remained the same at 57.382% when pulling 3f4750e0d3f38d9b3e333f6c56a1e2e880442b54 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage remained the same at 57.382% when pulling 3f4750e0d3f38d9b3e333f6c56a1e2e880442b54 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage remained the same at 57.382% when pulling e21fce24103cc613b25394a921926e4b8fd761b5 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage remained the same at 57.382% when pulling f03a9064969f0eed2a448c917a70262e5f968f11 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage remained the same at 57.382% when pulling f03a9064969f0eed2a448c917a70262e5f968f11 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage increased (+0.01%) to 57.395% when pulling 1bbb091928dbe5379a56017dedd3102126776583 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage increased (+0.01%) to 57.395% when pulling 1bbb091928dbe5379a56017dedd3102126776583 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage remained the same at 57.382% when pulling eb67faa2807a93b76fb5bb2597f09420553605e6 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage remained the same at 57.382% when pulling e087e5788d1c187b1621cd3280d674c429e3f7f0 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

Coverage remained the same at 57.382% when pulling 3961ce47652a4c1e8b4bc9c93e304bcb7cce8523 on translate-errors into d321a3672057e1433fe4942450ca8820dfbbf39d on aetherize.

authors: coveralls phoenixeliot


text:
Fixed #4382

Hello, i'm a new to open source so sorry in advance for anything, i could have gotten wrong.
I fixed the issue 4382. I added 3 new strings translation in the coffee.en ( and their corresponding translation in french ) cause i think there might be some language where u can't just translate it with 2 words or in the same order. So that's why i didnt concatenate from heroClass + adding a translation for "Only".
Any feedback is really appreciated.

Great work, @ntonon! I just merged this in. Thanks for not only figuring that out but also the other heroClass translation area.

authors: ntonon nwinter


text:
codecov-cli fails with Python 3.11

Steps to reproduce:
pip install codecov-cli
Collecting codecov-cli
  Downloading codecov_cli-0.5.0-cp311-cp311-win_amd64.whl.metadata (19 kB)
...
Successfully installed anyio-4.3.0 click-8.1.7 codecov-cli-0.5.0 h11-0.14.0 httpcore-0.16.3 httpx-0.23.3 ijson-3.2.3
pyyaml-6.0.1 responses-0.21.0 rfc3986-1.5.0 sniffio-1.3.1 tree-sitter-0.20.4

codecovcli do-upload
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Python311-x64\Scripts\codecovcli.exe\__main__.py", line 4, in <module>
  File "C:\Python311-x64\Lib\site-packages\codecov_cli\main.py", line 16, in <module>
    from codecov_cli.commands.staticanalysis import static_analysis
  File "C:\Python311-x64\Lib\site-packages\codecov_cli\commands\staticanalysis.py", line 10, in <module>
    from codecov_cli.services.staticanalysis import run_analysis_entrypoint
  File "C:\Python311-x64\Lib\site-packages\codecov_cli\services\staticanalysis\__init__.py", line 15, in <module>
    from codecov_cli.services.staticanalysis.analyzers import get_best_analyzer
  File "C:\Python311-x64\Lib\site-packages\codecov_cli\services\staticanalysis\analyzers\__init__.py", line 2, in <module>
    from codecov_cli.services.staticanalysis.analyzers.javascript_es6 import ES6Analyzer
  File "C:\Python311-x64\Lib\site-packages\codecov_cli\services\staticanalysis\analyzers\javascript_es6\__init__.py", line 5, in <module>
    import staticcodecov_languages
ModuleNotFoundError: No module named 'staticcodecov_languages'
Command exited with code 1

@xqt marking as duplicate of https://github.com/codecov/codecov-cli/issues/413

authors: thomasrockhu-codecov xqt

repo: codecov/codecov-cli


text:
Decode Ways- Solution added to the C++ folder

Description
Link to the problem: https://leetcode.com/problems/decode-ways/
The solution uses Dynamic Programming with memoization to obtain a solution with O(N) time complexity and O(N) space complexity. Steps have been explained in the solution itself via comments.
Put check marks:
Have you made changes in README file ?

[ ✓] Added problem & solution under correct topic.
[✓ ] Specified Space & Time complexity.
[ ✓] Specified difficulty level, tag & Note(if any).

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[ ✓] Test A (Input: s = "12" , Output: 2)
[✓ ] Test B (Input: s = "226" , Output: 3)
[✓ ] Test C (Input: s = "06" , Output: 0)

Make sure all below guidelines are followed else PR will get Reject:

[ ✓] My code follows the style guidelines of this project
[ ✓] I have performed a self-review of my own code
[ ✓] I have commented my code so that it is easy to understand
[✓ ] I have made corresponding changes to the documentation
[✓ ] My changes generate no new warnings
[✓ ] Any dependent changes have been merged and published in downstream modules

@VanshikaGupta17 we already have "Decode Ways" solution in readme under Dynamic Programming.
Update the readme accordingly

repo: codedecks-in/LeetCode-Solutions


text:
Add package auto discovery

Resolve #54

Codecov Report

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

@@            Coverage Diff            @@
##             master      #55   +/-   ##
=========================================
  Coverage     23.05%   23.05%
  Complexity      127      127
=========================================
  Files            14       14
  Lines           386      386
=========================================
  Hits             89       89
  Misses          297      297

Continue to review full report at Codecov.

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

authors: codecov-io codedge

repo: codedge/laravel-selfupdater


text:
fix ye olde none bug in #185

What changed

replaces email template subcategories with human friendly category names
fixed bug reported in #185 :bug: :skull:
none more nones

Issues

closes #185

Before :person_frowning::

After :smiley_cat::

LGTM

:+1:

authors: bsmithgall hamhands shellicious


text:
Redesign landing page with cards layout

Changes the landing page to use a card based layout for displaying offices and candidates.
It also adds a header sections with a button to toggle the address search bar, and a dropdown to select a district.
Note: this PR does not include an updated build and still have development settings. This is because I anticipate the desire to immediately iterate on this as there are still several other areas to address in the UI.
Initial view

Search bar can be toggled by button and hides after search

Cards show offices and candidates once a district is selected, or after a search

I removed the v-card-actions tags. Turns out, they didn't do anything anyways. Also, saved vue-style-loader as a dev dependency in the package.json file.

repo: codeforatlanta/atlanta-candidate-ui