Failed: 'consul_z1/0 is not running after update. Review logs for failed jobs: consul_agent, metron_agent

I am facing issue in bosh deploy. I am able to deploy all the instances but currently bosh deploy job is failing at updating consul server.
ubuntu@bosh:~/my-bosh$ bosh task
Acting as user 'admin' on 'my-bosh'

Director task 120
Deprecation: Ignoring cloud config. Manifest contains 'networks' section.

  Started preparing deployment > Preparing deployment. Done (00:00:01)

  Started preparing package compilation > Finding packages to compile. Done (00:00:00)

  Started updating instance consul_z1 > consul_z1/5046f1d6-c186-49ba-9a12-ee9b5744f7de (0) (canary). Failed: 'consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)' is not running after update. Review logs for failed jobs: consul_agent, metron_agent (00:11:29)

Error 400007: 'consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)' is not running after update. Review logs for failed jobs: consul_agent, metron_agent

Task 120 error

ubuntu@bosh:~/my-bosh$ bosh instances --ps
Acting as user 'admin' on deployment 'dev' on 'my-bosh'

Director task 126

Task 126 done

+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| Instance                                                                   | State   | AZ  | VM Type   | IPs           |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| api_z1/0 (cbc6ba2b-3fdb-4d7d-b2f6-c1f361958421)*                           | running | n/a | large_z1  | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| blobstore_z1/0 (a7107044-56fd-4c89-a301-4d410a3fc7fc)*                     | running | n/a | medium_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)*                        | failing | n/a | small_z1  | <IP_ADDRESS>  |
|   consul_agent                                                             | failing |     |           |               |
|   metron_agent                                                             | unknown |     |           |               |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| doppler_z1/0 (ef0ad2c1-21c1-4789-b105-953b47fc1966)*                       | running | n/a | medium_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| etcd_z1/0 (77dc4146-da01-4384-a4ba-1f5702a6b589)*                          | running | n/a | large_z1  | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| ha_proxy_z1/0 (8b87a71f-d107-475f-afb0-4f65fea86ec3)*                      | running | n/a | router_z1 | <IP_ADDRESS>  |
|                                                                            |         |     |           | <IP_ADDRESS> |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| hm9000_z1/0 (e3092889-0946-437a-8305-38b8f0e02b89)*                        | running | n/a | medium_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| loggregator_trafficcontroller_z1/0 (57f7b19f-9dd6-49f4-81b8-9c0987df19b8)* | running | n/a | small_z1  | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| nats_z1/0 (fbf4fb08-a7e6-491d-8946-bbb5e417f971)*                          | running | n/a | medium_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| postgres_z1/0 (30b76f99-9cb1-475d-bdac-8e51dc6bb596)*                      | running | n/a | medium_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| router_z1/0 (a3e0f407-036a-4579-b36f-8293e9e72928)*                        | running | n/a | router_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| runner_z1/0 (34a04fc4-6ba3-4187-9fc2-b2e88b1f69ea)*                        | running | n/a | runner_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| stats_z1/0 (1153c732-e379-426e-a8f9-af15e9a5126b)*                         | running | n/a | small_z1  | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+
| uaa_z1/0 (a382fc8d-756a-4123-b011-5938640f3015)*                           | running | n/a | medium_z1 | <IP_ADDRESS>  |
+----------------------------------------------------------------------------+---------+-----+-----------+---------------+

(*) Bootstrap node

# consul_z1/5046f1d6-c186-49ba-9a12-ee9b5744f7de:/var/vcap/data/sys/log/metron_agent# tailf metron_agent.stderr.log
 /var/vcap/data/packages/golang1.7/46105d4480ca083a6cafb8ca307d5e5084c655c4.1-b1cc5a7d126852f56020e81b66552b5f3cb1c6d2/src/runtime/panic.go:500 +0x1a1
main.main()
 /var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:79 +0x8ea
panic: Could not initialize doppler connection pool: tls: failed to find any PEM data in certificate input

goroutine 1 [running]:
panic(0xa20980, 0xc420173e80)
 /var/vcap/data/packages/golang1.7/46105d4480ca083a6cafb8ca307d5e5084c655c4.1-b1cc5a7d126852f56020e81b66552b5f3cb1c6d2/src/runtime/panic.go:500 +0x1a1
main.main()
 /var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:79 +0x8ea

# consul_z1/5046f1d6-c186-49ba-9a12-ee9b5744f7de:/var/vcap/data/sys/log/consul_agent# tailf agent_ctl.err.log
[2017-01-18 11:01:18+0000] ++ grep nameserver
[2017-01-18 11:01:18+0000] + local recursors
[2017-01-18 11:01:18+0000] + recursors=
[2017-01-18 11:01:18+0000] + for nameserver in '${nameservers[@]}'
[2017-01-18 11:01:18+0000] + recursors=' -recursor=<IP_ADDRESS>'
[2017-01-18 11:01:18+0000] + /var/vcap/packages/confab/bin/confab start -recursor=<IP_ADDRESS> --config-file /var/vcap/jobs/consul_agent/confab.json
[2017-01-18 11:01:18+0000] ++ logger -p user.info -t vcap.consul-agent
[2017-01-18 11:01:18+0000] ++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log
[2017-01-18 11:01:18+0000] ++ logger -p user.error -t vcap.consul-agent
[2017-01-18 11:01:18+0000] ++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stderr.log

# consul_z1/5046f1d6-c186-49ba-9a12-ee9b5744f7de:/var/vcap/data/sys/log/consul_agent# tailf consul_agent.stdout.log
{"timestamp":"1484737578.867382765","source":"confab","message":"confab.controller.write-service-definitions.write","log_level":1,"data":{}}
{"timestamp":"1484737578.867388725","source":"confab","message":"confab.controller.write-service-definitions.success","log_level":1,"data":{}}
{"timestamp":"1484737578.867396593","source":"confab","message":"confab.controller.boot-agent.run","log_level":1,"data":{}}
{"timestamp":"1484737578.867413998","source":"confab","message":"confab.agent-runner.run.start","log_level":1,"data":{"args":["agent","-config-dir=/var/vcap/jobs/consul_agent/config","-recursor=<IP_ADDRESS>"],"cmd":"/var/vcap/packages/consul/bin/consul"}}
{"timestamp":"1484737578.869066715","source":"confab","message":"confab.agent-runner.run.success","log_level":1,"data":{}}
{"timestamp":"1484737578.869156122","source":"confab","message":"confab.controller.boot-agent.agent-client.waiting-for-agent","log_level":1,"data":{}}
==> WARNING: LAN keyring exists but -encrypt given, using keyring
==> WARNING: WAN keyring exists but -encrypt given, using keyring
==> Starting Consul agent...
==> Error starting agent: Failed to start Consul server: Failed to parse any CA certificates

# Here are my cf deployment consul certificates:

consul:
    agent:
      domain: cf.internal
      log_level: null
      servers:
        lan:
        - <IP_ADDRESS>
    agent_cert: "-----BEGIN CERTIFICATE-----
certificate
-----END CERTIFICATE-----"
    agent_key: "-----BEGIN RSA PRIVATE KEY-----
certificate
-----END RSA PRIVATE KEY-----"
    ca_cert: "-----BEGIN CERTIFICATE-----
certificatte
-----END CERTIFICATE-----"
    dns_config: null
    encrypt_keys:
    - ecrypted_key
    server_cert: "-----BEGIN CERTIFICATE-----
certificate
-----END CERTIFICATE-----"
    server_key: "-----BEGIN RSA PRIVATE KEY-----
certificate
-----END RSA PRIVATE KEY-----"

ubuntu@bosh:~/my-bosh$ bosh task --debug
.
.
.
.
E, [2017-01-18 10:44:52 #18005] [canary_update(consul_z1/5046f1d6-c186-49ba-9a12-ee9b5744f7de (0))] ERROR -- DirectorJobRunner: Error updating canary instance: #<Bosh::Director::AgentJobNotRunning: 'consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)' is not running after update. Review logs for failed jobs: consul_agent, metron_agent>
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/state_applier.rb:48:in `post_start'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/state_applier.rb:30:in `apply'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater.rb:109:in `block in update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/instance_state.rb:5:in `with_instance_update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/instance_state.rb:11:in `with_instance_update_and_event_creation'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater.rb:111:in `update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:112:in `block (2 levels) in update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_formatter.rb:49:in `with_thread_name'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:110:in `block in update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/event_log.rb:99:in `advance_and_track'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:109:in `update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:104:in `block (2 levels) in update_canaries'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:77:in `block (2 levels) in create_thread'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:63:in `loop'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:63:in `block in create_thread'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/logging-1.8.2/lib/logging/diagnostic_context.rb:323:in `block in create_with_logging_context'
E, [2017-01-18 10:44:52 #18005] [] ERROR -- DirectorJobRunner: Worker thread raised exception: 'consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)' is not running after update. Review logs for failed jobs: consul_agent, metron_agent - /var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/state_applier.rb:48:in `post_start'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/state_applier.rb:30:in `apply'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater.rb:109:in `block in update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/instance_state.rb:5:in `with_instance_update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/instance_state.rb:11:in `with_instance_update_and_event_creation'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater.rb:111:in `update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:112:in `block (2 levels) in update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_formatter.rb:49:in `with_thread_name'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:110:in `block in update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/event_log.rb:99:in `advance_and_track'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:109:in `update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:104:in `block (2 levels) in update_canaries'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:77:in `block (2 levels) in create_thread'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:63:in `loop'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:63:in `block in create_thread'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/logging-1.8.2/lib/logging/diagnostic_context.rb:323:in `block in create_with_logging_context'
D, [2017-01-18 10:44:52 #18005] [] DEBUG -- DirectorJobRunner: Thread is no longer needed, cleaning up
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: Shutting down pool
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.010434s) SELECT NULL
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.000653s) SELECT "stemcells".* FROM "stemcells" INNER JOIN "deployments_stemcells" ON ("deployments_stemcells"."stemcell_id" = "stemcells"."id") WHERE ("deployments_stemcells"."deployment_id" = 41)
D, [2017-01-18 10:44:52 #18005] [] DEBUG -- DirectorJobRunner: Lock renewal thread exiting
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.000251s) SELECT NULL
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.000214s) SELECT NULL
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.000180s) SELECT NULL
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.006781s) DELETE FROM "locks" WHERE (("name" = 'lock:deployment:dev') AND ("uid" = '0c7c8183-a9a9-421e-a567-94f5467aa4ab'))
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: Deleted lock: lock:deployment:dev uid: 0c7c8183-a9a9-421e-a567-94f5467aa4ab
I, [2017-01-18 10:44:52 #18005] [task:120]  INFO -- DirectorJobRunner: sending update deployment error event
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: SENT: hm.director.alert {"id":"6edf333e-5f26-4eea-aeae-5d2eec6e1c8d","severity":3,"source":"director","title":"director - error during update deployment","summary":"Error during update deployment for 'dev' against Director 'e23b5aa1-d934-4176-a9c4-680c74c4b1f0': #<Bosh::Director::AgentJobNotRunning: 'consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)' is not running after update. Review logs for failed jobs: consul_agent, metron_agent>","created_at":1484736292}
E, [2017-01-18 10:44:52 #18005] [task:120] ERROR -- DirectorJobRunner: 'consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)' is not running after update. Review logs for failed jobs: consul_agent, metron_agent
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/state_applier.rb:48:in `post_start'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/state_applier.rb:30:in `apply'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater.rb:109:in `block in update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/instance_state.rb:5:in `with_instance_update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater/instance_state.rb:11:in `with_instance_update_and_event_creation'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/instance_updater.rb:111:in `update'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:112:in `block (2 levels) in update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_formatter.rb:49:in `with_thread_name'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:110:in `block in update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/event_log.rb:99:in `advance_and_track'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:109:in `update_canary_instance'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh-director-260.1.0/lib/bosh/director/job_updater.rb:104:in `block (2 levels) in update_canaries'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:77:in `block (2 levels) in create_thread'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:63:in `loop'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/bosh_common-260.1.0/lib/common/thread_pool.rb:63:in `block in create_thread'
/var/vcap/packages/director/gem_home/ruby/2.3.0/gems/logging-1.8.2/lib/logging/diagnostic_context.rb:323:in `block in create_with_logging_context'
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.000158s) SELECT NULL
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.000163s) BEGIN
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.000538s) UPDATE "tasks" SET "state" = 'error', "timestamp" = '2017-01-18 10:44:52.759486+0000', "description" = 'create deployment', "result" = '''consul_z1/0 (5046f1d6-c186-49ba-9a12-ee9b5744f7de)'' is not running after update. Review logs for failed jobs: consul_agent,...', "output" = '/var/vcap/store/director/tasks/120', "checkpoint_time" = '2017-01-18 10:33:17.973137+0000', "type" = 'update_deployment', "username" = 'admin', "deployment_name" = 'dev', "started_at" = '2017-01-18 10:33:17.973047+0000' WHERE ("id" = 120)
D, [2017-01-18 10:44:52 #18005] [task:120] DEBUG -- DirectorJobRunner: (0.005987s) COMMIT
I, [2017-01-18 10:44:52 #18005] []  INFO -- DirectorJobRunner: Task took 11 minutes 34.796910615 seconds to process.

Note: I have excluded certificate and key for security purpose.

@voelzmo Can you please help me out.

@harshalk91 You may want to try and post this issue at the https://github.com/cloudfoundry-community/consul-boshrelease repo. They'll be more familiar with how to configure this release.

Looks more like https://github.com/cloudfoundry-incubator/consul-release rather than the community one. Similar issues and resolutions from this search and this search might be a good first reference for troubleshooting.


Window resize or initially hidden display breaks list width

What happened?
In https://github.com/digitalfortress-tech/typeahead-standalone/blob/master/src/typeahead-standalone.ts#L139 the width of the list is set to the width of the input element initially.
This does not work in these cases:

when the window is resized and thus the input element, the list width is wrong
when the input is within a hidden container (for example a hidden tab), the width is set to 0

Simple solution would be to update the list width on every focus to the input element.
focusEventHandler
(Pseudo-Code, untested, but works in principle)
const focusEventHandler = (): void => {
  listContainer.style.width = `${input.offsetWidth}px`;
  ...

Affected version
Latest
Reproduction URL
https://jsfiddle.net/prm6hdv8/
How to reproduce?

Go to the link
Click button to show input
Start typing, list has width 0

Browsers
Chrome
Relevant log output
No response
Additional context
No response

@fellmann , Thanks for reporting this. Fixed in v5.3.2

Wow, thanks for the fast fix, much better than my proposition!

you're welcome! :)


App status

Checklist

[x] Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
[x] Any modified or new methods or classes have helpful JSDoc and code is thoroughly commented
[x] The description lists all applicable issues this PR seeks to resolve
[x] The description lists any configuration setting(s) that differ from the default settings
[x] All tests and CI builds passing

Description

Add application status page
Enhance deployment status panel

App status

Deployment status: Previous /New

Codecov Report

Merging #557 into dev will decrease coverage by 28.56%.
The diff coverage is 5.64%.

@@             Coverage Diff             @@
##              dev     #557       +/-   ##
===========================================
- Coverage   44.40%   15.84%   -28.57%
===========================================
  Files         314      315        +1
  Lines       17192    16127     -1065
  Branches     5263     4902      -361
===========================================
- Hits         7634     2555     -5079
- Misses       8336    11580     +3244
- Partials     1222     1992      +770

Flag
Coverage Δ

#end_to_end_tests
?

#unit_tests
15.84% <5.64%> (-0.06%)
:arrow_down:

Impacted Files
Coverage Δ

lib/admin/components/AdminPage.js
0.00% <0.00%> (-55.41%)
:arrow_down:

lib/admin/components/ApplicationStatus.js
0.00% <0.00%> (ø)

lib/common/components/EC2InstanceCard.js
17.39% <ø> (+0.24%)
:arrow_up:

lib/manager/components/DeploymentsPanel.js
68.68% <ø> (-2.47%)
:arrow_down:

lib/manager/reducers/status.js
28.99% <0.00%> (-39.11%)
:arrow_down:

lib/types/index.js
0.00% <ø> (ø)

lib/types/reducers.js
0.00% <ø> (ø)

lib/manager/components/CurrentDeploymentPanel.js
15.00% <6.55%> (-54.34%)
:arrow_down:

lib/admin/actions/admin.js
18.88% <20.00%> (-47.78%)
:arrow_down:

lib/manager/components/validation/TripsChart.js
0.00% <0.00%> (-80.40%)
:arrow_down:

... and 268 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 9db30ee...cf227df. Read the comment docs.

:tada: This PR is included in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


chore(deps): update all non-major dependencies

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-aws-modules/terraform-aws-route53
github
patch
v2.10.1 -> v2.10.2

github.com/terraform-aws-modules/terraform-aws-s3-bucket
github
patch
v3.6.0 -> v3.6.1

grafana (source)

patch
6.50.2 -> 6.50.3

kube-prometheus-stack (source)

minor
44.2.1 -> 44.3.0

tempo-distributed (source)

minor
0.27.19 -> 0.28.0

Release Notes

terraform-aws-modules/terraform-aws-route53
v2.10.2
Compare Source
2.10.2 (2023-01-24)
Bug Fixes

Use a version for  to avoid GitHub API rate limiting on CI workflows (#89) (30e4fb9)

terraform-aws-modules/terraform-aws-s3-bucket
v3.6.1
Compare Source
3.6.1 (2023-01-24)
Bug Fixes

Use a version for  to avoid GitHub API rate limiting on CI workflows (#204) (769f2f6)

grafana/helm-charts
v6.50.3
Compare Source
The leading tool for querying and visualizing time series and metrics.

prometheus-community/helm-charts
v44.3.0
Compare Source
kube-prometheus-stack collects Kubernetes manifests, Grafana dashboards, and Prometheus rules combined with documentation and scripts to provide easy to operate end-to-end Kubernetes cluster monitoring with Prometheus using the Prometheus Operator.

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Ran Plan for 6 projects:

dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
dir: external/iac/homelab/s3/mess-around-cdn workspace: default
dir: external/iac/homelab/s3/mess-around-kaniko workspace: default

1. dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_route53_zone.this[0]: Reading...
data.aws_route53_zone.this[0]: Read complete after 3s [id=Z04506812HGWLC3WX01A3]
aws_route53_record.this["* A"]: Refreshing state... [id=Z04506812HGWLC3WX01A3_*.homelab.linhng98.com_A]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/homelab.linhng98.com/records

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/homelab.linhng98.com/records

No changes. Your infrastructure matches the configuration.
2. dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
aws_route53_zone.this["homelab.linhng98.com"]: Refreshing state... [id=Z04506812HGWLC3WX01A3]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply" which may have affected this plan:

  # aws_route53_zone.this["homelab.linhng98.com"] has changed
  ~ resource "aws_route53_zone" "this" {
        id                  = "Z04506812HGWLC3WX01A3"
        name                = "homelab.linhng98.com"
      + primary_name_server = "ns-869.awsdns-44.net"
        tags                = {
            "Environment" = "homelab"
            "Owner"       = "linhng98"
            "Terraform"   = "true"
        }
        # (6 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

─────────────────────────────────────────────────────────────────────────────

Changes to Outputs:
  + route53_zone_zone_arn = {
      + "homelab.linhng98.com" = "arn:aws:route53:::hostedzone/Z04506812HGWLC3WX01A3"
    }

You can apply this plan to save these new output values to the Terraform
state, without changing any real infrastructure.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: /atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/homelab.linhng98.com/zones/default.tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "/atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/homelab.linhng98.com/zones/default.tfplan"
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/homelab.linhng98.com/zones

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/homelab.linhng98.com/zones

Note: Objects have changed outside of Terraform
3. dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_route53_zone.this[0]: Reading...
data.aws_route53_zone.this[0]: Read complete after 3s [id=Z03921783AB7FVK70V4RN]
aws_route53_record.this["* A"]: Refreshing state... [id=Z03921783AB7FVK70V4RN_*.istio.linhng98.com_A]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/istio.linhng98.com/records

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/istio.linhng98.com/records

No changes. Your infrastructure matches the configuration.
4. dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
aws_route53_zone.this["istio.linhng98.com"]: Refreshing state... [id=Z03921783AB7FVK70V4RN]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply" which may have affected this plan:

  # aws_route53_zone.this["istio.linhng98.com"] has changed
  ~ resource "aws_route53_zone" "this" {
        id                  = "Z03921783AB7FVK70V4RN"
        name                = "istio.linhng98.com"
      + primary_name_server = "ns-1656.awsdns-15.co.uk"
        tags                = {
            "Environment" = "homelab"
            "Owner"       = "linhng98"
            "Terraform"   = "true"
        }
        # (6 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

─────────────────────────────────────────────────────────────────────────────

Changes to Outputs:
  + route53_zone_zone_arn = {
      + "istio.linhng98.com" = "arn:aws:route53:::hostedzone/Z03921783AB7FVK70V4RN"
    }

You can apply this plan to save these new output values to the Terraform
state, without changing any real infrastructure.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: /atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/istio.linhng98.com/zones/default.tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "/atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/istio.linhng98.com/zones/default.tfplan"

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/istio.linhng98.com/zones

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/istio.linhng98.com/zones

Note: Objects have changed outside of Terraform
5. dir: external/iac/homelab/s3/mess-around-cdn workspace: default
Plan Failed: This project is currently locked by an unapplied plan from pull #42. To continue, delete the lock from #42 or apply that plan and merge the pull request.
Once the lock is released, comment atlantis plan here to re-plan.
6. dir: external/iac/homelab/s3/mess-around-kaniko workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 4.9.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_iam_policy_document.access_bucket_kaniko: Reading...
data.aws_canonical_user_id.this: Reading...
data.aws_caller_identity.current: Reading...
data.aws_iam_policy_document.access_bucket_kaniko: Read complete after 0s [id=1145461980]
aws_s3_bucket.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_iam_user.user: Refreshing state... [id=mess-around-kaniko-context]
aws_iam_policy.bucket: Refreshing state... [id=arn:aws:iam::370400765644:policy/mess-around-kaniko-context]
data.aws_canonical_user_id.this: Read complete after 0s [id=d065cb3fafdc3950c3d5af78dfcf2101d516c12010681525b23140444cb907d0]
data.aws_caller_identity.current: Read complete after 1s [id=370400765644]
aws_s3_bucket_public_access_block.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_s3_bucket_versioning.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_s3_bucket_acl.this[0]: Refreshing state... [id=mess-around-kaniko,private]
aws_iam_user_policy_attachment.aws_iam_policy: Refreshing state... [id=mess-around-kaniko-context-20220929024757757200000001]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/s3/mess-around-kaniko

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/s3/mess-around-kaniko

No changes. Your infrastructure matches the configuration.

atlantis plan

atlantis plan

Ran Plan for 6 projects:

dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
dir: external/iac/homelab/s3/mess-around-cdn workspace: default
dir: external/iac/homelab/s3/mess-around-kaniko workspace: default

1. dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_route53_zone.this[0]: Reading...
data.aws_route53_zone.this[0]: Read complete after 3s [id=Z04506812HGWLC3WX01A3]
aws_route53_record.this["* A"]: Refreshing state... [id=Z04506812HGWLC3WX01A3_*.homelab.linhng98.com_A]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/homelab.linhng98.com/records

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/homelab.linhng98.com/records

No changes. Your infrastructure matches the configuration.

2. dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
aws_route53_zone.this["homelab.linhng98.com"]: Refreshing state... [id=Z04506812HGWLC3WX01A3]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply" which may have affected this plan:

  # aws_route53_zone.this["homelab.linhng98.com"] has changed
  ~ resource "aws_route53_zone" "this" {
        id                  = "Z04506812HGWLC3WX01A3"
        name                = "homelab.linhng98.com"
      + primary_name_server = "ns-869.awsdns-44.net"
        tags                = {
            "Environment" = "homelab"
            "Owner"       = "linhng98"
            "Terraform"   = "true"
        }
        # (6 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

─────────────────────────────────────────────────────────────────────────────

Changes to Outputs:
  + route53_zone_zone_arn = {
      + "homelab.linhng98.com" = "arn:aws:route53:::hostedzone/Z04506812HGWLC3WX01A3"
    }

You can apply this plan to save these new output values to the Terraform
state, without changing any real infrastructure.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: /atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/homelab.linhng98.com/zones/default.tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "/atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/homelab.linhng98.com/zones/default.tfplan"
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/homelab.linhng98.com/zones

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/homelab.linhng98.com/zones

Note: Objects have changed outside of Terraform

3. dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_route53_zone.this[0]: Reading...
data.aws_route53_zone.this[0]: Read complete after 3s [id=Z03921783AB7FVK70V4RN]
aws_route53_record.this["* A"]: Refreshing state... [id=Z03921783AB7FVK70V4RN_*.istio.linhng98.com_A]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/istio.linhng98.com/records

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/istio.linhng98.com/records

No changes. Your infrastructure matches the configuration.

4. dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
aws_route53_zone.this["istio.linhng98.com"]: Refreshing state... [id=Z03921783AB7FVK70V4RN]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply" which may have affected this plan:

  # aws_route53_zone.this["istio.linhng98.com"] has changed
  ~ resource "aws_route53_zone" "this" {
        id                  = "Z03921783AB7FVK70V4RN"
        name                = "istio.linhng98.com"
      + primary_name_server = "ns-1656.awsdns-15.co.uk"
        tags                = {
            "Environment" = "homelab"
            "Owner"       = "linhng98"
            "Terraform"   = "true"
        }
        # (6 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

─────────────────────────────────────────────────────────────────────────────

Changes to Outputs:
  + route53_zone_zone_arn = {
      + "istio.linhng98.com" = "arn:aws:route53:::hostedzone/Z03921783AB7FVK70V4RN"
    }

You can apply this plan to save these new output values to the Terraform
state, without changing any real infrastructure.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: /atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/istio.linhng98.com/zones/default.tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "/atlantis-data/repos/linhng98/mess-around/43/default/external/iac/homelab/route53/istio.linhng98.com/zones/default.tfplan"
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/istio.linhng98.com/zones

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/istio.linhng98.com/zones

Note: Objects have changed outside of Terraform

5. dir: external/iac/homelab/s3/mess-around-cdn workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 4.9.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_canonical_user_id.this: Reading...
data.aws_caller_identity.current: Reading...
aws_s3_bucket.this[0]: Refreshing state... [id=mess-around-cdn]
data.aws_canonical_user_id.this: Read complete after 1s [id=d065cb3fafdc3950c3d5af78dfcf2101d516c12010681525b23140444cb907d0]
data.aws_caller_identity.current: Read complete after 1s [id=370400765644]
aws_s3_bucket_acl.this[0]: Refreshing state... [id=mess-around-cdn,public-read]
aws_s3_bucket_versioning.this[0]: Refreshing state... [id=mess-around-cdn]
data.aws_iam_policy_document.combined[0]: Reading...
data.aws_iam_policy_document.combined[0]: Read complete after 0s [id=1732306810]
aws_s3_bucket_policy.this[0]: Refreshing state... [id=mess-around-cdn]
aws_s3_bucket_public_access_block.this[0]: Refreshing state... [id=mess-around-cdn]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/s3/mess-around-cdn

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/s3/mess-around-cdn

No changes. Your infrastructure matches the configuration.

6. dir: external/iac/homelab/s3/mess-around-kaniko workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 4.9.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_canonical_user_id.this: Reading...
data.aws_iam_policy_document.access_bucket_kaniko: Reading...
aws_iam_user.user: Refreshing state... [id=mess-around-kaniko-context]
data.aws_caller_identity.current: Reading...
data.aws_iam_policy_document.access_bucket_kaniko: Read complete after 0s [id=1145461980]
aws_s3_bucket.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_iam_policy.bucket: Refreshing state... [id=arn:aws:iam::370400765644:policy/mess-around-kaniko-context]
data.aws_canonical_user_id.this: Read complete after 0s [id=d065cb3fafdc3950c3d5af78dfcf2101d516c12010681525b23140444cb907d0]
aws_s3_bucket_versioning.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_s3_bucket_acl.this[0]: Refreshing state... [id=mess-around-kaniko,private]
data.aws_caller_identity.current: Read complete after 1s [id=370400765644]
aws_s3_bucket_public_access_block.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_iam_user_policy_attachment.aws_iam_policy: Refreshing state... [id=mess-around-kaniko-context-20220929024757757200000001]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/s3/mess-around-kaniko

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/s3/mess-around-kaniko

No changes. Your infrastructure matches the configuration.

:fast_forward: To apply all unapplied plans from this pull request, comment:

atlantis apply

:put_litter_in_its_place: To delete all plans and locks for the PR, comment:

atlantis unlock

atlantis apply

Ran Plan for 6 projects:

dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
dir: external/iac/homelab/s3/mess-around-cdn workspace: default
dir: external/iac/homelab/s3/mess-around-kaniko workspace: default

1. dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_route53_zone.this[0]: Reading...
data.aws_route53_zone.this[0]: Read complete after 2s [id=Z04506812HGWLC3WX01A3]
aws_route53_record.this["* A"]: Refreshing state... [id=Z04506812HGWLC3WX01A3_*.homelab.linhng98.com_A]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/homelab.linhng98.com/records

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/homelab.linhng98.com/records

No changes. Your infrastructure matches the configuration.

2. dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
aws_route53_zone.this["homelab.linhng98.com"]: Refreshing state... [id=Z04506812HGWLC3WX01A3]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/homelab.linhng98.com/zones

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/homelab.linhng98.com/zones

No changes. Your infrastructure matches the configuration.

3. dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_route53_zone.this[0]: Reading...
data.aws_route53_zone.this[0]: Read complete after 2s [id=Z03921783AB7FVK70V4RN]
aws_route53_record.this["* A"]: Refreshing state... [id=Z03921783AB7FVK70V4RN_*.istio.linhng98.com_A]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/istio.linhng98.com/records

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/istio.linhng98.com/records

No changes. Your infrastructure matches the configuration.

4. dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 2.49.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
aws_route53_zone.this["istio.linhng98.com"]: Refreshing state... [id=Z03921783AB7FVK70V4RN]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/route53/istio.linhng98.com/zones

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/route53/istio.linhng98.com/zones

No changes. Your infrastructure matches the configuration.

5. dir: external/iac/homelab/s3/mess-around-cdn workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 4.9.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_caller_identity.current: Reading...
data.aws_canonical_user_id.this: Reading...
aws_s3_bucket.this[0]: Refreshing state... [id=mess-around-cdn]
data.aws_canonical_user_id.this: Read complete after 1s [id=d065cb3fafdc3950c3d5af78dfcf2101d516c12010681525b23140444cb907d0]
data.aws_caller_identity.current: Read complete after 2s [id=370400765644]
aws_s3_bucket_acl.this[0]: Refreshing state... [id=mess-around-cdn,public-read]
data.aws_iam_policy_document.combined[0]: Reading...
aws_s3_bucket_versioning.this[0]: Refreshing state... [id=mess-around-cdn]
data.aws_iam_policy_document.combined[0]: Read complete after 0s [id=1732306810]
aws_s3_bucket_policy.this[0]: Refreshing state... [id=mess-around-cdn]
aws_s3_bucket_public_access_block.this[0]: Refreshing state... [id=mess-around-cdn]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/s3/mess-around-cdn

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/s3/mess-around-cdn

No changes. Your infrastructure matches the configuration.

6. dir: external/iac/homelab/s3/mess-around-kaniko workspace: default
Show Output
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 4.9.0"...
- Installing hashicorp/aws v4.51.0...
- Installed hashicorp/aws v4.51.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
data.aws_canonical_user_id.this: Reading...
aws_iam_user.user: Refreshing state... [id=mess-around-kaniko-context]
data.aws_iam_policy_document.access_bucket_kaniko: Reading...
data.aws_caller_identity.current: Reading...
data.aws_iam_policy_document.access_bucket_kaniko: Read complete after 0s [id=1145461980]
aws_s3_bucket.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_iam_policy.bucket: Refreshing state... [id=arn:aws:iam::370400765644:policy/mess-around-kaniko-context]
data.aws_canonical_user_id.this: Read complete after 0s [id=d065cb3fafdc3950c3d5af78dfcf2101d516c12010681525b23140444cb907d0]
aws_s3_bucket_acl.this[0]: Refreshing state... [id=mess-around-kaniko,private]
aws_s3_bucket_versioning.this[0]: Refreshing state... [id=mess-around-kaniko]
data.aws_caller_identity.current: Read complete after 1s [id=370400765644]
aws_s3_bucket_public_access_block.this[0]: Refreshing state... [id=mess-around-kaniko]
aws_iam_user_policy_attachment.aws_iam_policy: Refreshing state... [id=mess-around-kaniko-context-20220929024757757200000001]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

:arrow_forward: To apply this plan, comment:

atlantis apply -d external/iac/homelab/s3/mess-around-kaniko

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d external/iac/homelab/s3/mess-around-kaniko

No changes. Your infrastructure matches the configuration.

:fast_forward: To apply all unapplied plans from this pull request, comment:

atlantis apply

:put_litter_in_its_place: To delete all plans and locks for the PR, comment:

atlantis unlock

atlantis apply

Ran Apply for 6 projects:

dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
dir: external/iac/homelab/s3/mess-around-cdn workspace: default
dir: external/iac/homelab/s3/mess-around-kaniko workspace: default

1. dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

route53_record_fqdn = {
  "* A" = "*.homelab.linhng98.com"
}
route53_record_name = {
  "* A" = "*.homelab.linhng98.com"
}

2. dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
Show Output
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

route53_zone_name = {
  "homelab.linhng98.com" = "homelab.linhng98.com"
}
route53_zone_name_servers = {
  "homelab.linhng98.com" = tolist([
    "ns-1478.awsdns-56.org",
    "ns-1887.awsdns-43.co.uk",
    "ns-869.awsdns-44.net",
    "ns-93.awsdns-11.com",
  ])
}
route53_zone_zone_arn = {
  "homelab.linhng98.com" = "arn:aws:route53:::hostedzone/Z04506812HGWLC3WX01A3"
}
route53_zone_zone_id = {
  "homelab.linhng98.com" = "Z04506812HGWLC3WX01A3"
}

3. dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

route53_record_fqdn = {
  "* A" = "*.istio.linhng98.com"
}
route53_record_name = {
  "* A" = "*.istio.linhng98.com"
}

4. dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
Show Output
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

route53_zone_name = {
  "istio.linhng98.com" = "istio.linhng98.com"
}
route53_zone_name_servers = {
  "istio.linhng98.com" = tolist([
    "ns-1081.awsdns-07.org",
    "ns-1656.awsdns-15.co.uk",
    "ns-275.awsdns-34.com",
    "ns-855.awsdns-42.net",
  ])
}
route53_zone_zone_arn = {
  "istio.linhng98.com" = "arn:aws:route53:::hostedzone/Z03921783AB7FVK70V4RN"
}
route53_zone_zone_id = {
  "istio.linhng98.com" = "Z03921783AB7FVK70V4RN"
}

5. dir: external/iac/homelab/s3/mess-around-cdn workspace: default
Show Output
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

s3_bucket_arn = "arn:aws:s3:::mess-around-cdn"
s3_bucket_bucket_domain_name = "mess-around-cdn.s3.amazonaws.com"
s3_bucket_bucket_regional_domain_name = "mess-around-cdn.s3.ap-southeast-1.amazonaws.com"
s3_bucket_hosted_zone_id = "Z3O0J2DXBE1FTB"
s3_bucket_id = "mess-around-cdn"
s3_bucket_region = "ap-southeast-1"
s3_bucket_website_domain = ""
s3_bucket_website_endpoint = ""

6. dir: external/iac/homelab/s3/mess-around-kaniko workspace: default
Show Output
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

s3_bucket_arn = "arn:aws:s3:::mess-around-kaniko"
s3_bucket_bucket_domain_name = "mess-around-kaniko.s3.amazonaws.com"
s3_bucket_bucket_regional_domain_name = "mess-around-kaniko.s3.ap-southeast-1.amazonaws.com"
s3_bucket_hosted_zone_id = "Z3O0J2DXBE1FTB"
s3_bucket_id = "mess-around-kaniko"
s3_bucket_region = "ap-southeast-1"
s3_bucket_website_domain = ""
s3_bucket_website_endpoint = ""

Locks and plans deleted for the projects and workspaces modified in this pull request:

dir: external/iac/homelab/route53/homelab.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/homelab.linhng98.com/zones workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/records workspace: default
dir: external/iac/homelab/route53/istio.linhng98.com/zones workspace: default
dir: external/iac/homelab/s3/mess-around-cdn workspace: default
dir: external/iac/homelab/s3/mess-around-kaniko workspace: default


Non-staff cannot delete deletable flags

From https://forum.inaturalist.org/t/impossible-to-delete-flags/21120 I can replicate with my test account.

With a non-staff account, flag something.
Immediately to the flag's page then delete the flag.
Page changes but the flag still exists.

Staff can still delete flags.

I think this was deliberate, perhaps due to this slack convo. I probably just didn't remove the delete button.
So I guess I'll repeat the question in case your mind has changed: is there ever a good reason to delete a flag?

See here https://forum.inaturalist.org/t/delete-withdraw-flags-that-you-created/17153/

Yeah, I mentioned some in the issue I created: https://github.com/inaturalist/inaturalist/issues/2852

Ok, so from that issue, the new requirement is that a user can delete a flag if

[ ] the user created it and no one else has commented on it
[ ] the user created it and it is unresolved


Media is not supported

it seems like all my media/data files are not supported.
I try to extract media from unencrypted iphone backup, the media folder is extracted and there is access to the media.
but the html files don't any media or link path for the media.
(the backup date is 03.2022)

Are you working on Windows/Linux/MacOS?

@KnugiHK I second that media (images,Voice notes) is not supported in html (Screenshot Attached )

@UsamaAshfaq Can you show me the working directory structure and the command issued?

@KnugiHK Sure. Command issued is : wtsexporter -a and working directory's SS is attached.

The Media folder should be inside the WhatsApp directory. This is because users are assumed to copy the whole WhatsApp directory from their shared storage directly.

It worked. I was looking for a way, to view my old backed up data on pc for more than 2 months. and now I am able to, thanks to you. Thank you very much ❤


querying data by toggling on client

Hi,
I just wanna querying data (all checked (true and false) data are publish on client) by toggling checked variable but I get data just for the first time actually by initialization ( getData() is also placed in ngOnInit() wrapped by MeteorObservable.subscribe ) and never more by toggling. What Am I doing wrong ?
Thanks for any help
Michal
checked:boolean = false
getData(){
Tasks.find({checked: this.checked})
  .map(tasks => tasks.length)
  .subscribe(todoCount => console.log(todoCount));
}

Actually it is working but If no tasks are found, subscribe is not fired. I'd expect that result is will be empty array. Why is it so ?
Thanks

Hi,
I have the same issue. I don't know how to handle it.

My solution was that every time before getData() was called, I empty array and If Task.find will be called array will be filled else array is empty.

Thx for your comment.
On my side, I would like to insert in the bd something when the result of the query is 0... So I can't go with your solution.
I found something else, did you try to wrap your code in:
MeteorObservable.subscribe('MYSUBSCRIPTION', MYSUBSCRIPTIONARGS).subscribe(() => {
      MeteorObservable.autorun().subscribe(() => {

              //YOUR CODE

      });
 });

It look like it's working for me!

unfortunately it is not working for me :(

@msio777 you set a publication from the server?
It worked for me after that!

solution is startWith
Tasks.find({checked: this.checked}).startWith([]).map(tasks => tasks.length).subscribe(todoCount => console.log(todoCount)); }


Rework CFCppBase to remove Impl classes and the Details namespace.

Adds support for calling non-nullary constructors on the new CF Type.
Removes the _CFFinalize chain.
Removes the _CFInitialize chain.
Uses some dodgy methods to work around the undefined behaviour
inherent in placement-newing a block of partially-initialized memory

This change is

:shipit:

:shipit:

:shipit:


🐛 Definitions not being parsed and added to context

Pre-requisites

[X] I checked the documentation and found no answer.
[X] I checked to make sure that this issue has not already been filed.

What version of the AaC package are you using? Check your version with the command: aac version.
0.4.11
Description
When I parse a model with req traces I'm not getting a listing of all the defined reqs.  There's nothing different or strange about how these are defined that I can see.  But interestingly it is consistent, run after run the same reqs fail to be recognized.
Reproduction URL
No response
Reproduction steps
Parse the sample here:  https://github.com/DevOps-MBSE/aac-doc-mdl/blob/main/tests/samples/trade_study/doc/cookie_trade_study.aac

Get all the `req` items from the context and you'll see there are some missing items.

Screenshots
If applicable, add screenshots to help explain your problem.
![DESCRIPTION](LINK.png)

Logs
Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.

Pertinent Files
Tip: You can attach images or log files by clicking this area to highlight it and then dragging files in.

I went ahead and created the parse-bug branch so that I could drop in a test case that demonstrates the issue.
You can run behave -i ./features/trade_study.feature --no-capture to see the issue...and it is weird.
When I parse the sample model, everything seems fine.  I check all my counts and even every value and come out clean.  But when I run the check it looks like values just "disappear" from the context and req.id references fail to check when I've already shown that they exist.  Certainly more investigation to do here.


Downloaded document broken

Hi,
I tried translating a document using the new upload functionality. It appears to work, except - the downloaded file is truncated in some way.
Upload is 54784bytes of a word .docx file witha bunch of pages of text and a table.
Download is always below 4k in size.
Using curl directly with the same file it translates nicely and gets me the full one back, so its not the file breaking DeepL, but somewhere in rust.
Sorry, I can't point to anything directly right now, just copied your code (and adjusted variable names) and run with it... Maybe you can successfully reproduce?
Greetings
Ganneff

Do you have the content of the downloaded file?

It is actually a zip file that (if you look with less) starts with PK, then some "garbage", then "docProps/core.xml" and later docProps/app.xml and word/document.xml, so I doubt the error response. Pretty similar to the looks of a regular file.
The part of the code around this is:
                let ffile = working.to_str().unwrap();
                let upload_file = UploadDocumentProp::builder()
                    .target_lang(target)
                    .file_path(&ffile)
                    .build();
                let response = api.upload_document(upload_file).await?;
                let mut status = api.check_document_status(&response).await?;
                loop {
                    if status.status.is_done() {
                        info!(
                            "Document {}, Billed Characters: {}",
                            ffile,
                            status.billed_characters.unwrap()
                        );
                        break;
                    }
                    trace!(
                        "Need to wait more, it says: {}",
                        status.seconds_remaining.unwrap()
                    );
                    if let Some(msg) = status.error_message {
                        return Err(anyhow!("Translation failed: {}", msg));
                    }
                    tokio::time::sleep(std::time::Duration::from_secs(3)).await;
                    status = api.check_document_status(&response).await?;
                }
                // After translation done, download it
                let path = api
                    .download_document(&response, "translated.docx", None)
                    .await?;

 I overwrite a part of the response over and over again into the same position of the file. I don't test it out because my test data is small enough to write into file at once. But for large file, the later bytes will overwrite the bytes before.

My character limit exceed... This issue might be fixed, but I can't test it now.

This issue is fixed in your fix-download branch, I just set it up to test. That is, I cloned your repo and used deepl-rs using path= in Cargo.toml, rebuild (it got some new toki-stream/syn/tokio-macros libs) and tried with the same file yesterday after adjusting my code for the PathBuf input.
I do have to fix the output name on my side, but the translated and downloaded file now works flawlessly, so IMO you can merge this and release.
THANKS for this!

This issue is fixed in your fix-download branch, I just set it up to test. That is, I cloned your repo and used deepl-rs using path= in Cargo.toml, rebuild (it got some new toki-stream/syn/tokio-macros libs) and tried with the same file yesterday after adjusting my code for the PathBuf input.
I do have to fix the output name on my side, but the translated and downloaded file now works flawlessly, so IMO you can merge this and release.
THANKS for this!

Can you successfully open the downloaded file? I am worry about if it is working or not...

I did, yes. Tried with two files, thats the "now works flawlessly".

Great! I will merge and release new version now.


Test if RS is still working on iOS and Android

This is related to https://github.com/WoWs-Info/WoWs-Info-End/issues/64 as it may not work anymore. The game may also updated the way how recording works.

RS is still working on Android. iOS is not tested yet.

This is proven to be working at the moment. It runs exactly the way it should be on Android.


Controlling Threads in MFXVideoDECODE

Hi
Referring to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1144 discussion, I am looking for ways to exercise finer control on decoder’s thread, i.e., their numbers and termination. From what I’ve gathered, I need to invoke MFXInitEx with par.ExternalThreads set to 1, and somehow pass worker threads to MFXDoWork. Not sure how to pass worker threads to  MFXDoWork; however, is there a sample code anywhere?
Cheers,

This MFXDoWork API is not supported (deprecated).
But you can control a number of internal MediaSDK threads (which belong to a scheduler) by https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxextthreadsparam . Please note that a min number of threads is two.

Thank you Dmitry. Is it possible to terminate these threads manually, e.g., is it possible to get their pid?
Cheers,

You're welcome. Unfortunately, app can't control them. The only way to terminate them is to close MSDK session.
Could you share background why you're interested in manual control? Too many internal MSDK threads or ... ?

Thank you again Dmitry. As noted in the original post, in Gitlab, the issue is a malformed input stream that upon wrap around leaves 8 threads behind. (Even though, MFXVideoDECODE_Close is called.) Looking at gdb output, it seems that these threads are stuck at pthread_wait_cond. (I’ve also tried  MFXVideoDECODE_Reset prior to close.) Also, kindly, note that our base code is about a year old.
Cheers,

No problem!
I looked thru the gitlab description but didn't get: is any bug behind it or just curiosity?

Thank you for the followup. It's indeed a bug, as our regression test is failing on this input stream, i.e., system's memory gets exhausted after 24 hours.

Hmm. This doesn't seem to be related to MSDK threads, right? If so, I'd propose to track it into another issue. Is it okay for you? Please post details about the stream and ideally a reproducer.

Hi @navesta ,
Could you reply?

Hi Dmitry,
Sorry didn't have a chance to reply earlier. The reason for suggesting that these are MSDK threads was based on the discussion on the Gitlab thread, where it was asserted that decoder creates as many threads as there are number of cores. Admittedly, I have not had a chance to confirm this by InitEx and specifying a different number of threads. Once I do, I’ll update this thread.
Cheers,

Hi Nastooh,
Thank you. Take your time.


how to use the regression loss to train the splitbrain？

I am reimplementing the Split brain on my dataset, the my network is here:
the path of ab->L:(input:84,84,2)->(42,42,16)->(21,21,32)->(21,21,32)->(11,11,64), and the feature(11,11,64) is average pooled across channel, get a (11,11,1)map, than, the loss is the L2 loss between the pooled feature map (11,11,1) and the downsampled L channel of the original image (11,11,1), the downsample operation is (84,84,1)->(11,11,1),
I do not know whether my reimplementation is correct, please help me, thanks a lot!

Thanks for trying to reimplement! The averaging across feature channels in the last layer seems potentially problematic. See Table 6 for the architecture here: https://arxiv.org/pdf/1611.09842.pdf . Thanks!


Add support for LDAP with SSL

In the in-built implementation the end-users have to imports the certificates directly into java's cacerts. This is usually problematic as users may move to a different system and their ldap authentication stops working suddenly. The issue also comes if their switch to a different version of java. They need to re-import all the certs. Since this is moving to a plugin, could we provide an option in auth-config for the plugin to specify the certs in order to avoid the same issue that we have with the in-built one.

hi @maheshp could you please describe teh procedure for adding a certificate into gocd in order this plugin to work ?

the process of setting up a certificate to work with LDAPS looks like this:
keytool  -import -storepass changeit -noprompt -alias xxx  -keystore /usr/lib/jvm/java-1.8.0-openjdk-<IP_ADDRESS>.b12-0.el7_5.x86_64/jre/lib/security/cacerts -trustcacerts -file xxx
Certificate was added to keystore

and then in order to trust the certificate you do what is described here:
https://www.happyassassin.net/2015/01/14/trusting-additional-cas-in-fedora-rhel-centos-dont-append-to-etcpkitlscertsca-bundle-crt-or-etcpkitlscert-pem/

@nskalis ,
I have 2 questions regarding your suggestion:

When I run this command, does everything about adding certificate to keystore happen LOCALLY ONLY?
I will be using my company's SSL certificates. How safe is it to add and trust the certificate by this way?

For the upcoming folks:
If you try to bind to Azure AD, make sure to this url ldaps://[DNS or IP]:636 :)
Since the certificate is not self-signed it works out of the box.


get_field_kind is added.

get_field_kind is added to compact_reader

Windows test PASSed.

Linux test PASSed.

Windows test PASSed.

Linux test PASSed.


Drop Python 3.6 support?

Can we drop Python 3.6 support?  @keflavich, @astrofrog ?

I'd prefer not to until CASA6 moves to >3.6.  Is there anything in >=3.7 we need?

OK, thanks.  I was hoping to drop 3.6 to 1) simplify the CI matrix and 2) be consistent with astropy core (and other packages that have adopted NEP-29; https://numpy.org/neps/nep-0029-deprecation_policy.html) so we can move regions into astropy.regions.
Do you know when CASA6 will be Python 3.7+?  We won't be able to move regions to astropy core until we drop Python 3.6.  Python 3.6 is EOL Dec 23, 2021.

I'd really like to get regions into astropy for 5.0 (feature freeze 10/29/2021).

I'm happy to set astropy 5.0 as a goal.  I don't know when CASA will move to py3.7, though if I find a timeline I'll try to remember to post it here.


@@router/INIT_PATH doesn't work with initalState?

Hi, I have this setup of my store:
const finalCreateStore = compose(
  autoRehydrate(),
  applyMiddleware(thunk, logger),
)(createStore);

const store = finalCreateStore(reducer, {
  routing: {
    path: `/contacts/30/about`,
  },
});

and then at app.jsx I use syncReduxAndRouter(history, store).
When I start my app redux-simple-router ignores my initialState with routing.path. Why?

Hi @theaqua, thanks for the input. I just don't think we ever thought about this use-case. I played around with this now, but got into a problem with our tests that makes this difficult right now.
So it's definitely possible to implement, but I think we need to solve the test issue before adding this (but we're very open to PRs, so if someone has an idea, please try it out and see if it works!)
@jlongster The problem as far as I can see is that initialState is "global state" across invocations of syncReduxAndRouter. My initial idea was to do something like this:
if (!lastRoute) {
  // if getRouterState() is set, default to that
  // otherwise do what we do today
}

But that won't work in the tests as getRouterState() will only be "correct" on the first invocation of syncReduxAndRouter (so I got the feature working, but the tests failed, but they didn't fail "in the right way", as the test ran when I only ran the failing test).
I think we need to consider moving everything into a function that you invoke (similar to createHistory), so we get an "instance" of redux-simple-router that you work with. I think that might simplify some cases — but I really haven't gone through all the details, it just "feels" right. My next week will be busy, but I'll try to play around with ideas when I've got the time.

Yeah, it's not great that we change initialState from a single syncReduxAndRouter. Although I'd argue that you really can only sync once across your whole app. I'm open to other ways to set it up though.
This might be fixed by adding:
  if(getRouterState().path) {
    lastRoute = getRouterState();
  }

Right when syncReduxAndRouter is called. But I'm not sure. I'm going through issues and trying to build up context for where we stand.

Yep, no problem in apps, only a problem in the tests

This is fixed in 2.0.0 AFAIK.


update companies add lendis.io

Adds the following events or companies:

Lendis

Checklist

[x] I have updated the event or company counts
[x] I have put the most recent relevant date in the "Last Update" column
[ ] I have linked to the article about the change, not the company's website

The article has not yet being finished, will update as soon as available

The change looks fine, but it has a merge conflict that GitHub won't let me resolve.
Would you mind taking care of it?
Thanks!

@drewbrew surely. here you go


Add uber/orbit like model in pymc example

Add uber/orbit like model example jupyter notebook. Refer to https://github.com/pymc-labs/pymc-marketing/issues/43

:books: Documentation preview :books:: https://pymc-marketing--250.org.readthedocs.build/en/250/

Thank you for opening this PR @thipokKub ! As discussed in https://github.com/pymc-labs/pymc-marketing/issues/43, we do not need to merge this one but rather take it as a first step toward the implementation. FYI: @ricardoV94 @lucianopaz

Hi guys, I'm trying to follow the PRs around time-varying coefficients. Do you already have an implementation around this? I would like to share an implementation that I manage to apply but I'm not sure if it's worth it, or if you already solved it.

@carlangastr This has been a bit inactive so not sure if this will progress. We currently don't have a solution for this so it would be great to see what you came up with!


Support ASP.Net Core 2.0 to Microsoft.Bot.Builder

convert project file to support .Net Standard 2.0
convert each project file

Microsoft.Bot.Builder
Microsoft.Bot.Builder.Autofac
Microsoft.Bot.Connector.AspNetCore
Microsoft.Bot.Connector.NetCore

add bot framework authentication to Microsoft.Bot.Connector.AspNetCore with ASP.Net Core 2

add Setup.cs
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication().AddBot("{AppId}", "{AppPassword}");
}

add MessagesController.cs
[BotAuthentication]
[HttpPost]
public async Task Post([FromBody]Activity activity)

Any info when support for ASPNet Core 2.0 will be available?

Hi @yakumo
Thank you for your contribution!  However, there is already a Pull Request being reviewed that provides support for .NET Core 2.0: https://github.com/Microsoft/BotBuilder/pull/3472  Please check out that PR, and provide some comments if you believe it can be improved upon.
@Hrcinjo #3472 is currently under review.  We do not have a timeline for when it will be merged.

Hi, @Hrcinjo
I am sorry that my English is not good.
Subject mean 'I made BotBuilder work on ASP.NetCore 2' I wanted to write.
I don't check any pull request.
Hi, @EricDahlvang
OK.
I merge to #3472, and close this request.


eComm Marketing Page Issues

Example: https://main--shredit--stericycle.aem.live/en-us/marketing/ecomm
o	Icon for Select Is Missing
o	Icons are too large
o	CTAs under each section are missing
Should look like:

@MarquiseRosier looks much better. One small issue the buttons appear to be rendered in hover state (black outline around button). Can you fix?


TypeError: create() got multiple values for keyword argument 'dl_tfms'

I've got this error when running 03. NSynth (Audio Classification by Computing Spectrograms On-the-fly).ipynb.
It fails in the following cell:
batch_size = 64

instrument_family_pattern = r'(\w+)_\w+_\d+-\d+-\d+.wav$'

data = (AudioItemList
            .from_folder(NSYNTH_AUDIO)
            .filter_by_func(lambda fn: 'acoustic' in fn.name)
            .split_by_folder()
            .label_from_re(instrument_family_pattern)
            .databunch(bs=batch_size, tfms=tfms))

Apparently there have been some changes in fastai parameter names. It can be solved changing tfms=tfms to dl_tfms=tfms and then the corresponding changes in AudioDataBunch


WANT A FULLSCREEN MODE

Hey developer , as Kiwi is the most feature rich browser on Android , will you please consider giving us Fullscreen mode as it will make the browsing experience more seamless .❤❤😍😍😘😘👍👍

Please use the right template issue to suggest a new feature to be added on Kiwi


Manpage clean-up

I've gone through the reference pages and cleaned up some unwieldy example outputs as suggested in #450. I mainly spotted three big issues.

In 41688b42620ef319909e51bb08dff6ddf13b3f49, I've used head() to avoid printing the whole probability matrix in https://microbiome.github.io/mia/reference/calculateDMN.html.
In 13a55fb98987868c67f8522195f4e81a4f6f54f9, I've removed rows with zero standard deviation from the assay to eliminate the large warning chunks in https://microbiome.github.io/mia/reference/getExperimentCrossAssociation.html. The second assay used in the example also has some NA values, but I haven't changed those since they don't produce too many warnings, and one of the examples demonstrates the use of show_warnings=FALSE.
In ecf30870a57b1715ecc8f9323e8d362efe22f587, I've reduced the number of artificially created groups to reduce repetitive warnings in https://microbiome.github.io/mia/reference/splitOn.html. These warnings ultimately stem from addTaxonomyTree, which is called for each split object created from the original when update_rowTree = TRUE. I don't think this is the best solution, perhaps these could be suppressed instead?

In addition, I've fixed some grammar mistakes here and there.

Thanks!
Could @TuomasBorman check what to do with "n https://github.com/microbiome/mia/commit/ecf30870a57b1715ecc8f9323e8d362efe22f587, I've reduced the number of artificially created groups to reduce repetitive warnings in https://microbiome.github.io/mia/reference/splitOn.html. These warnings ultimately stem from addTaxonomyTree, which is called for each split object created from the original when update_rowTree = TRUE. I don't think this is the best solution, perhaps these could be suppressed instead?"