input-output-hk / iohk-ops Goto Github PK

Tomas updates the release notes (and perhaps other content?) on daedaluswallet.io every release. When DevOps proposes the new mainnet installers on the blockchain, we also update the daedalus-latest.version.json so the installer links on the website are updated without manual intervention.

I suggest we work toward having all standard release-related updates encoded in the daedalus-latest-version.json file. Otherwise, we have complicated timing issues where DevOps has been asked to do the update in the middle of Tomas' night.

Previous issue: https://iohk.myjetbrains.com/youtrack/issue/DEVOPS-904

Build of iohk-ops fails with the the next message:
error: build of ‘/nix/store/jf1jwbkii4b3cyd19k701wr6rbivdsan-cardano-sl-36f9fcc.drv’ failed

If I checkout to slow-fallocate branch and move to slow-fallocate directory, then build fails too with similar message:
error: build of ‘/nix/store/jf1jwbkii4b3cyd19k701wr6rbivdsan-cardano-sl-36f9fcc.drv’ failed

Currently we have a document benchmarks/Benchmarks.md which explains how to launch benchmarking on a cluster and collect results. Unfortunately, this document is incomplete and contains some out-of-date info. We have to improve it.

These two lines

https://github.com/input-output-hk/iohk-ops/blame/master/docs/Daedalus-Installer-Update-Procedure.md#L95
https://github.com/input-output-hk/iohk-ops/blame/master/docs/Daedalus-Installer-Update-Procedure.md#L264

link to

https://github.com/input-output-hk/iohk-ops/blob/c5a9412dac5fb9d4870112250f6fb1d951275272/docs/Daedalus-installer-history

which 404s.

(same suggestion posted in deadalus repository)

It looks like a noticeable number of users has problems using Daedalus just because their computer (AV Suite) or local network (LAN/WAN) does not allow connections to the 7 bootstrap servers listening on port 3000
I would suggest introducing a fallback on port 443 (HTTPS) or a complete switch to such a standard port.

I believe that we're on track to fix this via the new virtualized mac builders, but this is a tracking issue for how things are progressing.

See also:

• input-output-hk/tools#4
• IntersectMBO/plutus#1076

Currently adding a new repo to hydra for CI involves editing at least three files. Which can be seen for example in #578. This is quite ergonomically and prone to errors (I think).

It would be pretty cool if we had a json file that looked something like this:

[
  ...
  , { "loony tools": "https://github.com/input-output-hk/tools" }
  ...
]

from which this scaffolding that's currently needed would be driven. Maybe optionally have a key bors: true if borsng should be enabled on that repo or not.

This file is used by all GAC-based deployments for the purpose of sharing
configuration parameters between NixOS VMs/instances and the Nixops configs that
deploy them. It also contains some definitions of AWS resources. While the
configuration-parameter management aspect of it is needed by all GAC
deployments, the AWS resources are only needed by deployments to AWS instances.
We therefore need to be able to include those parts separately.

• configure hydra to report both serokell and Cardano jobs
• fix PR building for cardano-shell
• update branch protection settings on iohk-ops
• report statuses for cardano-wallet
• report Cardano status for daedalus
• update ouroboros-network branch protection
• update cardano-sl branch protection
• update plutus branch protection
• verify bors.toml is updated on cardano-ledger

Need to have a monitoring server with the following for each deployment:

• prometheus
• alertmanager
• grafana
• all services behind oauth_proxy
• integration with pagerduty
• statsd exporter for metrics for applications providing metrics
• node exporter on all nodes in deployment
• nginx /w vts monitoring on any nginx hosts (including monitoring host)
• deadmansnitch to alert if prometheus server is down (PD integration as well)

• Notification Queue
• Eval times
• Slow mac builds
• Number of builds per slave to low
• sending/receiving inputs/outputs between slave and master

Failure is on PR : input-output-hk/cardano-shell#202

Build kite log : https://buildkite.com/input-output-hk/cardano-shell/builds/697#2680a4c8-a22f-4866-9aa8-a0a71a561445

As our COMODO-issued Windows code signing certificate is set to expire on Mar 29, we need it reissued and re-installed on AppVeyor.

• re-issue the code signing certificate
• integrate the new certificate on AppVeyor builds
• verify the new installers are recognised as signed by the Window OS

Previous issue: https://iohk.myjetbrains.com/youtrack/issue/DEVOPS-1238

Related PR #500

Set buildkite thresholds to 0.9 and 0.95