pipでハッシュが一致しないエラー 2020/10/11
(penv0) pi@raspberrypi:~/Documents/py $ pip install opencv-python==3.4.11.41
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Collecting opencv-python==3.4.11.41
Downloading https://www.piwheels.org/simple/opencv-python/opencv_python-3.4.11.41-cp37-cp37m-linux_armv7l.whl (9.3MB)
92% |█████████████████████████████▊ | 8.6MB 20kB/s eta 0:00:34
THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
opencv-python==3.4.11.41 from https://www.piwheels.org/simple/opencv-python/opencv_python-3.4.11.41-cp37-cp37m-linux_armv7l.whl#sha256=7298c55e59f00b7f72a20621072b381a40cd3b4be03d07e60235949e98bd620f:
Expected sha256 7298c55e59f00b7f72a20621072b381a40cd3b4be03d07e60235949e98bd620f
Got dd1a2a12a0c8147a42c0e44a52cbd73200d89427eed8766c784c1e422f35c5f1
なにこれ．
ハッシュがどうにも一致してないらしい． そこで
pip install https://www.piwheels.org/simple/opencv-python/opencv_python-3.4.11.41-cp37-cp37m-linux_armv7l.whl
を叩いたが失敗．うーん．
なので，
wget https://www.piwheels.org/simple/opencv-python/opencv_python-3.4.11.41-cp37-cp37m-linux_armv7l.whl
ってして
pip install opencv_python-3.4.11.41-cp37-cp37m-linux_armv7l.whl
ってしたらできた．
DockerでCUDAを扱う際に生じたトラブル:Error response from daemon: OCI runtime create failed: unable to retrieve OCI runtime error 2020/10/16
確認するべきは
*CUDAのバージョン* >= イメージ"nvidia/cudaのバージョン"
であるかどうか．これなら問題は無いはず．
以下，余談
ubuntu18.04をnvidia-driver:450. CUDA version: 11.0で動かしていたが， 20/10/16時点におけるnvidia/cudaの最新バージョンはCUDA version: 11.1に対応したものだった．
docker run --gpus all nvidia/cuda:latest
とすると，
まさにこのエラーが発生する．
イメージのバージョンが高すぎたためにエラーが発生した．
またイメージがCUDA version:9.0をpullした場合は無事に動く．
REPOSITORY TAG IMAGE ID CREATED SIZE nvidia/cuda 11.0-devel-ubuntu18.04 d89f75c1799d 5 days ago 3.74GB nvidia/cuda 9.0-base bd52bf936aec 2 weeks ago 144MB ubuntu latest 9140108b62dc 2 weeks ago 72.9MB kilin@kilin-ubu18:~/Documents/env0/docker_config$ docker run -it --gpus all nvidia/cuda:9.0-base root@d4ca4a757de2:/# nvidia- bash: nvidia-: command not found root@d4ca4a757de2:/# nvidia-smi Thu Oct 15 15:55:15 2020 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 450.51.05 Driver Version: 450.51.05 CUDA Version: 11.0 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 GeForce GTX 166... On | 00000000:09:00.0 Off | N/A | | 31% 35C P8 12W / 125W | 193MiB / 5941MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| +-----------------------------------------------------------------------------+ root@d4ca4a757de2:/#
OpenCV4.4.0でCUDAを利用する備忘録 2020/10/21
膨大な数のエラーと格闘したので覚えている範囲でメモ
はじめに
-D WITH_CUDA=ON
OpenCV contributeをインストールして、CUDAいれる．
aptでnvidiaドライバをインストールした場合
この場合，一緒に
sudo apt install nvidia-cuda-toolkit
で，cudaをインストールしている場合がある．
nvcc -V
と叩いてこのバージョンとnvidia-smiのバージョンが一致しているかを確かめる必要がある．
不一致だから動かないというわけでは無いが，nvidiaドライバとcudaのバージョン(nvcc -V)に不整合がある場合，動作保証がされていない．
つまりnvidia-smiの右上に表示される"CUDA Version"と実際にインストールするべきcudaのバージョンを合わせればいい．
で，上記のaptでtoolkitからcudaをインストールした場合，恐らくcuda-9.0が入っている(20/10)(nvccにwhich使うと/usrに入っていたため気づくのが遅れた)
なので，公式からダウンロード．そして入っているcuda-9.0はuninstallしてもいいし，もしくは
export PATH="/usr/local/cuda-11.0/bin:$PATH" export LD_LIBLARY_PATH="/usr/local/cuda-11.0/lib64"
としておくのが賢い．場所は特に指定しなければ/usr/local以下にcudaが存在する．nvidia-smiでみえているからと言って、パスが通っていない場合がある。今回の環境構築でここにハマっていた。
cudaフラグをたててビルド
今回の環境は以下
$uname -a Linux kilin-ubu18 5.4.0-51-generic #56~18.04.1-Ubuntu SMP Tue Oct 6 09:47:18 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $nvcc -V $ nvcc -V nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2020 NVIDIA Corporation Built on Thu_Jun_11_22:26:38_PDT_2020 Cuda compilation tools, release 11.0, V11.0.194 Build cuda_11.0_bu.TC445_37.28540450_0 $ nvidia-smi Wed Oct 21 03:37:47 2020 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 450.51.05 Driver Version: 450.51.05 CUDA Version: 11.0 | |-------------------------------+----------------------+----------------------+
今回のビルドスクリプトは以下，
https://github.com/kilinlili/dockerfile_for_cuda/blob/master/cmake.sh
フラグに関していくつかメモをしておく．
今回はcuDNNはOFFにしている．
ONにする場合は，
-D WITH_CUDNN=ON \
-D WITH_OPENCV_DNN_CUDA=ON \
を渡す．cudaとは別にインストールが必要なので注意．
aarch64等，armv8ならばSIMDのNEONが使えるため，
-D ENABLE_NEON=ON \
が使える．しかしながら，X86_64(AMD64)の場合は，CMakeの実行でエラーを吐くためこのパラメータは利用しない．
CUDA_ARCHの指定は，今回の環境であれば7.5だけでいい．指定が無い場合，ビルドに時間がかかるためフラグをたてることを勧める． この時CUDA_ARCH_PTXを指定した場合，ビルド時にnvcc fatalエラーとなった．なのでBINのみ指定をしている． これで無事にビルドができた．
エラー
pythonで実行検証 stackoverflow.com
C++で実行検証 (-218:No OpenGL support) Library was built without OpenGL support in function 'cvNamedWindow'
sudo apt install libgtkglext1 libgtkglext1-dev
して再度ビルド．
CMake時の結果と渡したフラグくらいキチンと確認するべきだなと思った．
avcodecやFFMPEGがonにならない場合，恐らく何かが不足している．
sudo apt install libavcodec-dev libavformat-dev libswscale-dev
をしてみた再度cmakeしてみるとできる可能性がある．
人間は愚か 2020/12/6 17:00
醤油
醤油ボトル
はい
HHKBをばらす
はい
はい
乾燥
はい
いかがでしたか？
チャンネル登録と高評価をお願いいたしま！！！！！！1！！！111
【読書memo】プロジェクトマネジメントの基本が全部わかる本
通読したので、個人的に重要と思った点及び現在の自身の状況を踏まえつつコメントを残す
1章:
- プロジェクトはスタートとゴールが決まってる
- プロジェクトは不確定要素が多い
- 全体感の共有が足りないとうまくいかない
- 関係性構築がうまくできていない。
- 全体を俯瞰して「優先対処が必要な課題はなにか？」に取り組む人が所謂マネージャという人。
- PMが人と金、PdMが人とモノを管理するイメージ。
2章: 交渉
- コミュニケーションに抵抗はないが、交渉技術はまた別の話だと思うから注意したい。
- 交渉って結構精神面でハードな場合が多い。
- QCDバランスを取りながら調整しないといけなくてまぁ難しいよね
- 自分がマネジメントするエンジニアもそうだけど、顧客とのヒアリングは定期的に行っていくの大事
- 同期・非同期/言語・非言語コミュニケーション手段は適切に。心配ないと思うけど。
- 議事録で証拠を残す
- 仲の良さと信頼関係は別物。人がやめていく場合は信頼関係が構築できてない〜と書かれていたが、人がやめるのは今の時代色々複合的なのでなんとも。。。
3章: タスクマネジメント
- ジョブ型とメンバーシップ型。今の時代は前者がプロジェクトにとってふさわしい。アジャイルとかまさにこういうのでまわしていかないとだよね。
- モチベの低いメンバーがいる場合はすぐに上に報告らしい。わからんでもない。
- 「やってみないとわからない」と判断するエンジニア、これ経験値が低いかやる気がないです。はい。
- 基本的にタスクは「期間」じゃなくて「工数」で考えると良い。
- タスクの依頼の仕方は、背景や理由を説明する。信頼関係構築にも忠誠にもつながる
- 毎日進捗確認するのいいね。で、報告する側も正しく報告するの大事ね。
- 特定個人にタスクをふると遅い場合があるが、これは個人の問題ではなくやり口の問題。こちらでなんとか誘導してあげるべき。
FYI: ガントチャート
- タスクの抜けが発生しやすい
- 締切直前にやり切るみたいなやり口でやられる可能性が高い。結構やりがち。
4章: プロジェクト計画
- 必須条件を決めていくような形。
5章: 見積もり
- いつ見積もりを実施するかで精度が当然変わる。
- 概算見積と詳細見積もりの使い分け。
- 概算ってあるけど、ちゃんと根拠もってやれよ？(悪癖)
- 炎上理由として見積もりがおおざっぱすぎたとかいうのはよくある話。
6章: 契約
7章: 要件定義
- QCDに影響を及ぼすかどうかは、ここで5割決まるとか
- 要求と要件って言葉は覚えておきたい。混在して理解しているから使い分けるべき。
- ビジネス要件がめちゃくちゃ軽視されがちだけど、PMのスコープではあるからマジ大事。
- 市場調査、競合調査
- ビジネスモデル
- KPIツリー
- KPIの可視化だね。
- ペルソナ設計
- プロダクト利用者を想定しながら進める手法
- ユーザーヒアリング
- ペルソナに該当するユーザに予めヒアリング。予めどんなペイン、ニーズがあるか確認する方法。インタービューだね。
- カスタマージャーニーマップ
- ユーザーストーリーマップ
業務フローとかはtoBなシステムだとマストで考えるよね。
図示して進める合意を得るのは正しい。だけどパワポ使うんじゃねぇとのこと。Cacooやdraw.ioを使うほうが好ましい。
- ToBeとAsIsみたいな考え方は知らなかった。覚えておこう。
8章: デザイン
- 割愛
9章: 設計
- あるべき姿や構造・構成を決めていく作業
- この章の設計書のページは丸暗記しておいてもいいかもね。結構難しいし、自分で書いた設計書は情報が最小限で構成されてる。引き出しの少なさが原因なので知っていてほしい。
10章: テスト
- 7原則があるよってことを知っておこう。これを頭に叩き込めてたらOK
11章: リリース
- リリース計画を毎回立てていることはわかっているのでOK。意図や背景までわかるといいね。
12章: 保守・改善
- 損益分岐点がこんなところでもでてくる
- 投資した費用を売上が超えてくる点がそれ。黒字ってやつ。
- ファネルモデルは知っておこう
感想
- 課長からカツアゲした本なんだけど、結構いい本。読みやすかった。
- 明らかに情報が
aws lambda layer構築中にThe plugin.(*GRPCProvider).ApplyResourceChange request was cancelled.でコケる。
lambda layerを構築していたが、何故かデプロイできなくなった。
とりあえずデバッグフラグ。
kilin@kilin:~/$ env | grep TF_LOG TF_LOG=DEBUG
確認。
2024-04-27T21:38:53.960+0900 [TRACE] evalApplyProvisioners: module.guess_api.aws_lambda_layer_version.lambda_layer is tainted, so skipping provisioning
2024-04-27T21:38:53.961+0900 [TRACE] maybeTainted: module.guess_api.aws_lambda_layer_version.lambda_layer was already tainted, so nothing to do
2024-04-27T21:38:53.961+0900 [TRACE] terraform.contextPlugins: Schema for provider "registry.terraform.io/hashicorp/aws" is in the global cache
2024-04-27T21:38:53.961+0900 [TRACE] NodeAbstractResouceInstance.writeResourceInstanceState to workingState for module.guess_api.aws_lambda_layer_version.lambda_layer
2024-04-27T21:38:53.961+0900 [TRACE] NodeAbstractResouceInstance.writeResourceInstanceState: removing state object for module.guess_api.aws_lambda_layer_version.lambda_layer
2024-04-27T21:38:53.971+0900 [TRACE] statemgr.Filesystem: not making a backup, because the new snapshot is identical to the old
2024-04-27T21:38:53.973+0900 [TRACE] statemgr.Filesystem: no state changes since last snapshot
2024-04-27T21:38:53.973+0900 [TRACE] statemgr.Filesystem: writing snapshot at terraform.tfstate
2024-04-27T21:38:53.976+0900 [DEBUG] State storage *statemgr.Filesystem declined to persist a state snapshot
2024-04-27T21:38:53.976+0900 [ERROR] vertex "module.guess_api.aws_lambda_layer_version.lambda_layer" error: Request cancelled
2024-04-27T21:38:53.977+0900 [TRACE] vertex "module.guess_api.aws_lambda_layer_version.lambda_layer": visit complete, with errors
2024-04-27T21:38:53.980+0900 [TRACE] dag/walk: upstream of "module.guess_api.aws_lambda_function.guess_api_lambda (expand)" errored, so skipping
2024-04-27T21:38:53.981+0900 [TRACE] dag/walk: upstream of "module.guess_api.aws_lambda_function.guess_api_lambda" errored, so skipping
2024-04-27T21:38:53.982+0900 [TRACE] dag/walk: upstream of "module.guess_api (close)" errored, so skipping
2024-04-27T21:38:53.982+0900 [TRACE] dag/walk: upstream of "provider[\"registry.terraform.io/hashicorp/aws\"] (close)" errored, so skipping
2024-04-27T21:38:53.982+0900 [TRACE] dag/walk: upstream of "root" errored, so skipping
2024-04-27T21:38:53.984+0900 [TRACE] terraform.contextPlugins: Schema for provider "registry.terraform.io/hashicorp/aws" is in the global cache
2024-04-27T21:38:53.984+0900 [TRACE] statemgr.Filesystem: not making a backup, because the new snapshot is identical to the old
2024-04-27T21:38:53.985+0900 [TRACE] statemgr.Filesystem: no state changes since last snapshot
2024-04-27T21:38:53.985+0900 [TRACE] statemgr.Filesystem: writing snapshot at terraform.tfstate
╷
│ Error: Request cancelled
│
│ with module.guess_api.aws_lambda_layer_version.lambda_layer,
│ on ../modules/lambda/main.tf line 88, in resource "aws_lambda_layer_version" "lambda_layer":
│ 88: resource "aws_lambda_layer_version" "lambda_layer" {
│
│ The plugin.(*GRPCProvider).ApplyResourceChange request was cancelled.
╵
2024-04-27T21:38:53.998+0900 [TRACE] statemgr.Filesystem: removing lock metadata file .terraform.tfstate.lock.info
2024-04-27T21:38:53.999+0900 [TRACE] statemgr.Filesystem: unlocking terraform.tfstate using fcntl flock
2024-04-27T21:38:54.002+0900 [DEBUG] provider: plugin exited
よくわからない。ログ実際のログはTRACEしている箇所もある。ひとまずログが長すぎてどうしようもないためERRORだけで引っ掛けてみる。
TF_LOG=ERROR terraform apply
しかし、
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
module.guess_api.aws_lambda_layer_version.lambda_layer: Creating...
module.guess_api.aws_lambda_layer_version.lambda_layer: Still creating... [10s elapsed]
2024-04-27T21:45:42.466+0900 [ERROR] plugin.(*GRPCProvider).ApplyResourceChange: error="rpc error: code = Canceled desc = context canceled"
2024-04-27T21:45:42.495+0900 [ERROR] vertex "module.guess_api.aws_lambda_layer_version.lambda_layer" error: Request cancelled
╷
│ Error: Request cancelled
│
│ with module.guess_api.aws_lambda_layer_version.lambda_layer,
│ on ../modules/lambda/main.tf line 88, in resource "aws_lambda_layer_version" "lambda_layer":
│ 88: resource "aws_lambda_layer_version" "lambda_layer" {
│
│ The plugin.(*GRPCProvider).ApplyResourceChange request was cancelled.
╵
(lambda-env) kilin@kilin-B450-I-AORUS-PRO-WIFI:~/Documents/Project/climbApp/terraform/dev$
駄目みたい。
一応確認したが、terraform planしても特に問題が見当たらない。
2024-04-27T21:36:45.765+0900 [INFO] backend/local: plan operation completed
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
~ update in-place
Terraform will perform the following actions:
# module.guess_api.aws_lambda_function.guess_api_lambda will be updated in-place
~ resource "aws_lambda_function" "guess_api_lambda" {
id = "guessApi-dev"
~ layers = [
- "arn:aws:lambda:ap-northeast-1:369311474110:layer:lambda_layer_climb:4",
] -> (known after apply)
tags = {}
# (27 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
# module.guess_api.aws_lambda_layer_version.lambda_layer will be created
+ resource "aws_lambda_layer_version" "lambda_layer" {
+ arn = (known after apply)
+ compatible_runtimes = [
+ "python3.10",
]
+ created_date = (known after apply)
+ filename = "../modules/lambda/python.zip"
+ id = (known after apply)
+ layer_arn = (known after apply)
+ layer_name = "lambda_layer_climb"
+ signing_job_arn = (known after apply)
+ signing_profile_version_arn = (known after apply)
+ skip_destroy = false
+ source_code_hash = "rmQ+NESv0D/ezoyMc/Z8zBTWn6fK0hnrV9FpJRKGlQA="
+ source_code_size = (known after apply)
+ version = (known after apply)
}
Plan: 1 to add, 1 to change, 0 to destroy.
この辺の記事を読んでもイマイチよくわからず。
原因がわからないと思ったが、そもそもultralyticsで色々放り込んだな？と思い出し、ファイル容量を確認する。
du -sh ./*
2.4GBのデプロイ用zipファイルが存在した。これだ。
サイズを小さくして再度apply。
Enter a value: yes module.guess_api.aws_lambda_layer_version.lambda_layer: Creating... module.guess_api.aws_lambda_layer_version.lambda_layer: Creation complete after 5s [id=arn:aws:lambda:ap-northeast-1:369311474110:layer:lambda_layer_climb:5] module.guess_api.aws_lambda_function.guess_api_lambda: Modifying... [id=guessApi-dev] module.guess_api.aws_lambda_function.guess_api_lambda: Modifications complete after 8s [id=guessApi-dev] Apply complete! Resources: 1 added, 1 changed, 0 destroyed.
OK。
lambda layerのアップロードサイズ上限は50MB(圧縮後)
terraform側では上限に引っかかった旨のエラーは表示されない様子だった。 zipファイルサイズを小さくしてデプロイし直すとデプロイできたので、サイズ上限に引っかかったということがわかる。
こちらによると圧縮zipで50MBで解凍後に250MB以下でないといけないらしい。 今回はlayerサイズのクォータ制限を回避する形で対応を行った。
