openSUSE.Asia Summit 2022 ロゴ募集

By Syuta Hashimoto @ 2022-07-19 21:15

※訳者コメント:去年のロゴはHaruo Yoshino さんの作品が採用されました。ロゴ応募はサミットに参加する形の一つだと思いますので、ぜひご応募ください。

私達はopenSUSE.Asia Summit 2022のロゴコンテストを開始します。ロゴはサミットの成功に必要不可欠な要素です。ご存知の通り、過去のopenSUSE.Asia Summitには、サミットが開催された地域・コミュニティを反映したユニークなロゴがあります。今年も前例に習って今年のサミットに相応しいロゴを集めるためにロゴコンテストを開催します。注意して頂きたいこととして、今年のサミットは2つのパートにわかれています。1つはバーチャルオンラインカンファレンスで行うアジアサミットメイントラック、もう1つは各地域で開催されるローカルパートです。このロゴはアジアサミットメイントラック用になります。ですので、このロゴはアジアを表現するものとなります。

コンテストは現在開催されていて、2022年7月23日が締切となります。最優秀作品の作者には運営委員から感謝の気持ちとして「Geeko Mystery Box(なにが入っているかはお楽しみ)」を送らせて頂きます。

締切:2022年7月23日
最優秀作品発表:8月14日の週

ロゴコンテスト募集要項:

  • ロゴは CC-BY-SA 4.0 ライセンスに準拠する事とします。また、openSUSE.Asia Summit 2018においてあなたの作品をロゴとして使用する場合、帰属【attribution(BY)-著作権者の表示】なく使用出来る事とします。帰属(著作権者の表示)はサミットのウェブサイトで行います。
  • ロゴはオリジナルである事とし、第三者の制作物を含む等、上記の著作権者の表示の特別条項付きCC-BY-SA 4.0 に抵触してはいけません。
  • モノクロとカラーフォーマットの両方を必ず提出してください。
  • SVGフォーマットで提出してください。
  • デザインはアジアのopenSUSEコミュニティを反映するものにしてください。
  • ロゴは以下の項目を避けるよう、厳重な注意を払って下さい。
    • 何れかのブランド名や商標、及びそれらを連想させるもの
    • 不適切な表現、攻撃的な表現、ヘイト表現、苦痛を与える表現、中傷的な表現、他人の名誉を毀損するような表現
    • 性別を限定した表現、および性別に対して挑発的な表現
    • 暴力や武器を連想させるような表現
    • アルコール、煙草、ドラッグの使用を連想させるような表現
    • 人種、ジェンダー、信仰、国籍、身体障害、性的指向、年齢に関する差別表現
    • グループや個人に対する、偏見、人種差別、中傷、及び何らかの害を与えるような表現
    • 宗教、信条、国家主義を連想させるような表現
  • ロゴは、「openSUSEプロジェクトトレードマークガイドライン」に従ってください。
  • ブランディングガイドライン はロゴのデザインに役立ちます(オプション)。

提出方法:以下の内容と共にデザインをopensuseasia-summit@googlegroups.comに送信してください

  • 件名:openSUSE.Asia Summit 2022 Logo Design – [お名前]
  • 連絡先のお名前とメールアドレス
  • 設計の理念に関する文書(txtまたはpdf)
  • SVGフォーマットのベクターファイル(SVGフォーマットであることを確認してください)
  • 添付のビットマップ サイズ:256×256 px以上、PNGフォーマット
  • ファイルサイズ 512 KB未満

openSUSE.Asia Summit 実行委員は、ロゴがすべての要件を満たしていることを条件として、ロゴを決定します。最終的な決定はopenSUSE.Asia Summit 実行委員が行い、それは最高スコアのデザインではない場合もあります。作成者には、Inkscape を使用することをお勧めします。Inkscapeは、あらゆる種類のデザインのための、強力でフリーでオープンソースのベクトルグラフィックツールです。

openSUSE.Asia Summit 2022 発表提案募集

By Syuta Hashimoto @ 2022-07-19 21:00

※訳者注:セッションは英語での発表となります。また、英語版の告知より数日経っています。

本日、openSUSE.Asia Summit 2022 メイントラックの発表提案募集を告知できることをうれしく思います。openSUSE.Asia Summitの実行委員では、様々な活動背景や様々なオープンソースソフトウェアの推進者のスピーカーを探しています。 openSUSE.Asia Summitは毎年アジアでオープンソースソフトウェアを使うことを推進するために企画されており、openSUSEコミュニティ(コントリビューターとユーザーの両方)にその価値を認められているイベントです。昨年のインドチームによって開催されたバーチャルサミットに引き続き、8回目の開催となる openSUSE.Asia Summit 2022 は openSUSEオンラインボランティアチームによって、9月末に開催されます。過去のAsia Summitはインドネシア、中国、台湾、日本、韓国、インドなどから多くの方が参加しました。

今年のイベントは2パートから成ります:Asia Summit メイントラックと、それぞれのアジアの国/地域で開催される、オンラインやオフラインのローカルパートです。今回の募集はAsia Summitのメイントラックになります。Asia Summitメイントラックはオンラインカンファレンスツールを使ったオンラインでの開催のみとなります。トークは基本的にライブ中継になります。しかし、あらかじめ録画しておいたビデオを流す事も出来ます。

トピック

openSUSE.Asia Summit 2022は、openSUSEに関連するトピックや、次のようなトピックを募集しますークラウド、仮想化、コンテナ、コンテナオーケストレーション、Linuxデスクトップ環境やソフトウェアなど。なぜならopenSUSEは様々なFLOSSプロダクトを集めたものだからです。トピックの例は次のようなものですが、これらに限らなくても大丈夫です。

  • openSUSE(Leap、Tumbleweed、Open Build Service、openQA、YaST)
  • openSUSE Kubic & MicroOS、クラウド、仮想化、コンテテやコンテナオーケストレーション
  • 組み込みやIoT
  • セキュリティ(アクセス制御、暗号化、脆弱性マネジメント)
  • デスクトップ環境やソフトウェア(GNOME、KDE、XFCE)
  • オフィススイート、グラフィックスソフト、マルチメディア(LibreOffice、Calligra、GIMP、Inkscape)
  • 多言語対応(インプットメソッド、翻訳)
  • openSUSEで動いているその他のソフトウェア

技術的では無いトピックを歓迎していることにも注目してください。例えば以下のようなトピックです。

  • FLOSS技術の解説
  • 開発、品質保証、翻訳
  • Tips & Tricks、体験談(成功、失敗問わず)、ベストプラクティス
  • マーケティング、コミュニティマネジメント
  • 教育

セッションの種類

これらの2種類の発表提案を募集しています。

  • プレゼンテーションを使った、基調講演かロングトーク(30分+Q&A)
  • プレゼンテーション有り/無しどちらでもよしとする、ショートトーク(15分+Q&A)

オンラインセッションは聞き手が注意力を保つのが難しい為、トークは短く魅力的なものを心がけて下さい。

スケジュール

  • 締切:2022年7月31日
  • 採用通知:8月15日週
  • カンファレンス:
    • 9/30日(金) 10:00 UTC – 15:00 UTC(日本時間 19:00 – 24:00)
    • 10/1日(土) 4:00 UTC – 7:00 UTC(日本時間 13:00 – 16:00)

発表提案の登録方法

イベントページにご登録下さい。

  • 発表提案は英語で書いて下さい。また、適切なタイトルと共に、150〜500字の長さでお願いします。
  • 発表とスライドは英語でお願いします。
  • 登録前にスペルチェックや文法チェックを行うようお願いします。 LibreOffice Extensions Languagetool や、grammarly が使えます。
  • プロフィールの経歴も評価対象になります。ご自身の活動状態・背景を忘れずに記載して下さい。
  • openSUSE Conference code of Conduct に従って下さい。発表提案の登録成功後、詳細を入力するフォームのリンクが送付されます。

プロポーザル作成ガイド

発表提案がトピックに関するものや関連するものであることを明確にしてください

例えば、セキュリティやデスクトップアプリケーションに関するトークの場合、アプリケーションのインストールから始まると良いでしょう。

発表提案がそうである理由を含めて下さい

理由として次のようなものが含まれるでしょう

  • アプリケーション/技術/ソリューションに必要とされている
  • 提案されているソリューションの機能の展望
  • 想定聴者(初心者、貢献者)の学習

もし発表提案の書き方やプレゼンテーションの準備に不明な所や確認したい所があれば、お気軽にソーシャルメディアでローカルチームに連絡したり、運営委員に質問したりしてください。

運営委員連絡先

プログラムに関するご質問などは次のメールアドレスにお問い合わせ下さい。
opensuseasia-summit@googlegroups.com

それでは、openSUSE.Asia Summit 2022でお会いできることを楽しみにしています。

openSUSE.Asia Summit は、コントリビューターやファンがアジア全域から参加者が集まる、アジア地域の年次openSUSEカンファレンスです。このイベントでは、openSUSEディストリビューションとそのコミュニティ、個人や企業で使用するアプリケーション、そしてオープンソースの文化について、主に焦点を当てています。

2014年から、openSUSE.Asia Summitはオフラインで開催され、コミュニティの人たちが実際に会う非常に良い機会でした。しかしながら、COVID-19の影響により、2020年のサミットはキャンセルせざるを得ませんでした。そして2021年、サミットはインドチームによりオンラインで開催されました。

openSUSE.Asia Summit 2022はどうなる?

openSUSE.Asia Summit 2022はハイブリッドイベントとなります。

中心となるオンラインサミットと共に、各国/地域でのオフラインイベントをそれぞれ開催します。

アジア全体パート(オンライン + サテライトのオフライン)

  • 各アジア地域から参加しやすいよう、4:00 – 6:00 UTC(13:00 – 15:00 JST)を目安に開催します。
  • 基調講演、招待講演などを予定しています。

ローカルパート(オンライン/オフライン – 開催場所に依る)

  • 各国、各地は、COVID-19の影響や制限を熟慮した上で、オフラインイベントを開催することができます。
  • 開催内容はそれぞれの開催場所によって異なります。それぞれの開催場所で、トークセッション、ワークショップ、ミートアップなどが企画されます。

ボランティアにお願いしたいこと

このイベントを実現する為、ボランティアを募集しています。今年はボランティアはどの地域からでも参加できます。

ボランティアにお願いしたいことは以下の通りです。

  • アジア地域パートの準備の為のレギュラーオンラインミーティングに参加してください(今は金曜日の 13:00 UTC <22:00 JST>にSlackで行っています。)
  • ローカルパートのイベントを企画し、アジア地域パートとスケジュール調整を行ってください
  • オンラインカンファレンスを手伝い、ボランティア同士のミーティングのスケジュールを調整してください
  • オフラインイベントを開催してください(openSUSE.Asia Summitの実行委員に相談し、必要なサポートを受けることができます)

ボランティアに興味がありましたら、5月30日までに簡単な自己紹介と共にメールを opensuseasia-summit@googlegroups.com までお送りください。

原文はこちら

※訳者コメント※

今年のopenSUSE.Asia Summitは、メインのオンラインイベントと、各地域のローカルイベントのハイブリッド開催となりました。ボランティアスタッフには、オンラインイベント、ローカルイベントの両方(もしくは片方)のお手伝いをして頂ければと思っています。興味を持たれましたら、上記の実行委員連絡先や、ユーザ会の方へご連絡ください。疑問・質問なども遠慮なくお問い合わせください。

小ネタ:transactional serverでbtrfs balance

By Syuta Hashimoto @ 2020-12-23 01:30

諸事情で、MicroOSのルートにbtrfsの機能でディスクを追加したのですが、balasceを実行しようとすると「read onlyだよ」と警告が。

ユーザ会slackに投げてみた所、武山さんから「transactional-update shellの中ならいけるのでは?」との助言を頂きました。

結論

成功

コマンド

transactional-update shell

transactional-updateそのもののアップデートが行われた後、独自のシェルに移行しました。

transactional update #

この状態で書き込み可能になります。書き込み後、シェルを抜けてrebootすれば反映されるしくみですね。

btrfs balance /

前後の状態を撮り損ねてしまったのですが、無事にbalanceされてました。

transactional-updateの真価はまだ味わえてないので、ロールバック等含め、近いうちにまとめて検証してみたいですね。

そもそも、transactional-update shellが一体何をどうしているのかも追えていない・・・

ODC 2020 online 参加しました

By Syuta Hashimoto @ 2020-12-21 01:00

12/19(土)に開催された、ODC 2020 onlineに参加してきました。

Cross Distro Developers Camp

今回は、ディストリビューション横断で日本語入力の課題などを解決しようと結成されたチーム、Cross Distro Developers Campで参加してきました。


Linuxディストリビューション大集合 〜あなたのLinuxディストリビューションを見つけてみよう〜

ディストリビューションとはなんぞや?から、openSUSE、Debian、Solusの各ディストリビューションの紹介を行いました。

openSUSEは武山さんが紹介してくださいました。

Debianさんなど、あらためて説明を聞くと、特色や方向性が理解できて面白かったです。開発体制なんかも普段は目にすることがないので、興味深かったです。

Solusさんからは、日本語入力関連のパッケージの開発にまつわる、難題のお話も・・・・

休憩時間・雑談タイム

次のコマがミーティングだったので、間で雑談を。

参加者からは話題の?Centos8の事や、ターミナルでの日本語表示に関する問題などが出てました。

データの形式と、それを表示するソリューション(ターミナル)は独立しているべきですけど、ソリューション側で対応すると、それぞれのソリューションで日本語対応しなければならないことに・・

Linuxディストリビューション開発談話

openSUSEから武山さん、Debianから杉本さんがメインパネラーとして、あとはSolusのPG_MANAさん、ひよこLinux(?)の羽鳥さん、opencoconの島田さんにオブザーバーとして参加して頂いて、ディストリビューション開発について談話しました。

結構、ディストリビューション開発って(ソフトウェアもですが)敷居高いイメージありましたが、もちろん世界でどなたかが実際に開発しているわけで、方法もノウハウもあるわけですよね。

日本のコミュニティがそういった情報を持っているし、世界とのコネクションもあるので、まぁアクセスしてよ、とおっしゃってました。

私も来年はパッケージ開発何かしたいなぁ。

ブース

終日、JitsiをOSPNからお借りしてブース展示をしていました。私は主にこのブースの管理をしていました。

関係者の方?が多く入ってくださって、openSUSEユーザ会のRibbonさんとは、最近MLで話題になってた日本語manの話とかを聞けました。あとはみなさんと近況を連絡しあったり、と、普段はオフラインで開催している時にやってた情報交換ができた感じでよかったです。

新しい方はちょっと入りにくかったですかね・・私も無理に声掛けとかしなかったのですが、もうちょっと配慮してもよかったかもしれません。反省。そのあたり、東海道LUGの島田さんが上手にアプローチしてくださっていて、さすがだなぁと思いました。(島田さんには、セミナーのディストロとは?の所をお話して頂きまして、それもあってブースに来てくださってました。)

感想

セミナー・ミーティングは、Zoom 30人強、YouTube 40人弱で70人前後の方が見てくださってました。ありがとうございます。

openSUSEに興味持たれたら、ぜひアクセスしてください!

Cross Distro Developers Campとしては、次回活動は2021年1/31日(日)にもくもく会(オンライン)を予定しています。

起動するkubeletのバージョンを上げる

By Syuta Hashimoto @ 2020-12-17 01:00

私はKubicでKubernetesを構築しているのですが、Kuibcをアップデートしてkubeletのバージョンが1.19に上がったはずなのにもかかわらず、kubectl get nodeでずっとバージョンが1.18となっていて悩んでいました。

結論

/etc/sysconfig/kubelet に設定されている KUBELET_VERを、1.18から1.19に変更する

調査

パッケージを確認

まず、パッケージがなんのバージョンが入っているかを確認します。

kubic1-host:~ # zypper se kubelet

S  | Name                          | Summary                   | Type
—+——————————-+—————————+——–
i  | kubernetes-kubelet            | Kubernetes kubelet daemon | package
i  | kubernetes1.17-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.17-kubelet-common | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet        | Kubernetes kubelet daemon | package
i  | kubernetes1.18-kubelet-common | Kubernetes kubelet daemon | package
i+ | kubernetes1.19-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.19-kubelet-common | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet        | Kubernetes kubelet daemon | package
  | kubernetes1.20-kubelet-common | Kubernetes kubelet daemon | package

 どうやら、1.17、1.18、1.19、と、いろいろなバージョンが入ってるようです。

今見たら、1.20も入ってますね。

使ってるバイナリを確認

kubic1-host:~ # type kubelet

kubelet is hashed (/usr/bin/kubelet)

ふむふむ。/usr/bin/kubelet、ですね。

こういう実行ファイルはスクリプトの場合があったりするので、種別を調べてみます。

kubic1-host:~ # file /usr/bin/kubelet
/usr/bin/kubelet: POSIX shell script, ASCII text executable

なるほど、スクリプトっぽいですね。

中身を確認します。

kubic1-host:~ # cat /usr/bin/kubelet
#!/bin/sh
# Loader Script for Multi-Version Kubelet arrangement introduced to openSUSE in March 2020
source /etc/sysconfig/kubelet

if [ -z “$KUBELET_VER” ]       
then
  echo “ERROR: KUBELET_VER= not defined in /etc/sysconfig/kubelet”
  exit 1
else
  /usr/bin/kubelet$KUBELET_VER “$@”
fi

どうやら、/etc/sysconfig/kubeletの値を参照しているようです。こちらを確認してみます。

kubic1-host:~ # cat /etc/sysconfig/kubelet
KUBELET_VER=1.19
KUBELET_EXTRA_ARGS=”–container-runtime=remote –container-runtime-endpoint=unix:///var/run/crio/crio.sock –runtime-request-timeout=15m –c
group-driver=systemd -v=2 –runtime-cgroups=/systemd/system.slice –kubelet-cgroups=/systemd/system.slice”

なるほど、KUBELET_VERが定義されています。nodeのバージョンが低いときは、ここが1.18となっていましたので、それを1.19に更新しました。

それからKubernetesを起動すると、見事バージョンが1.19にあがってました。

今なら1.20に上がる予感・・・・

メーリングリスト

最近忙しいこともあって、なかなかメーリングリストなどの情報源にあたれず・・・もしかしたら、こういったことはとうに情報共有されていたのかもしれません。また、この設定がKubic独自なのか、一般的なのか、といったことも追いきれておらず。追って調査したいと思います。

そもそもの使い方

アップデートで使い続けるのではなく、折を見て最新プリメイドイメージに乗り換えていく運用が今っぽいのかも・・・・・

Kubernetesのメモリ使用量を測ってみる

By Syuta Hashimoto @ 2020-12-07 00:10

某LUGで、Kubernetesのメモリ使用量を気にされていたので、測ってみました。

結論

masterノードはKubernetes起動後、1.3G前後のメモリを使用。workerは、コンテナを動かせば動かしただけメモリを使用。15pod程度では、2つのworkerでそれぞれ1G使わない程度でした。

方針

KVM上にKubicを展開して、そこでKubernetesを動かします。

VMの起動のみの状態、Kubernetesを起動した状態、いくつかのpodを動かした状態、で、freeや、topのメモリ使用量上位10のプロセスを拾ってみます。

また、Kubernetes起動後はcrictl statsの結果も見てみます。今回、IDを名前で置き換えていますのでご注意下さい。(通常のcrictl statsですと、IDのみの表示となり名前は表示されません。)

環境

  • Kubernetes
    • master 1 worker 2 構成
    • KVM上で動かす
    • OSはKubic
    • CPU数 master 2 worker 1
    • メモリ それぞれ 3G
    • Kubernetes 1.19.4
  • ホスト
    • openSUSE 15.2
    • CPU Ryzen 3900
    • メモリ 32G

Kubic・・・openSUSEプロジェクトで開発している、Kubernetes専用OSです。Tumbleweedをベースにしていて、Kubernetesを動かすことに焦点を絞ったパッケージ構成&システム設定。プリビルドなイメージが毎日のように公開されるため、ignitionなどの初期設定ツールを使って手早く最新Kubernetesを展開できます。

Ryzen 3900・・・コア数12なので、VMは結構たてられます。目指せおうちクラウド。

ちなみに、saltstackのマスター用VMを別途立てていて、各ゲストは基本的にそこから制御しています。(今回のコマンド実行は直接各ゲストで行いました。)

VMの起動のみ

起動のみの状態

master

worker1

worker2

利用可能メモリが、3台とも2.5G程度であることがわかります。

Kubernetes起動後

Kubernetesとネットワークアドオンのweaveを起動します。

master

worker1

worker2

masterがさらに1G程使用しました。workerは数百程度の使用にとどまっています。

podを幾つか起動した後

15個程podを走らせてみます。

走らせたサービスは、Promeheus、Grafana、DokuWiki、Nextcloud、Harborなどです。

master

worker1

worker2

masterの使用量はほとんどかわりませんが、動いたpod分、両workerのメモリが使用された感じです。

参考までに、pod一覧です。

感想

色々と検証しているときは、clairが1G以上メモリを使ったりしていましたが、今回計測しているときは100Mいかないぐらいでした。当然ですが、podの起動だけでなく、実際に使ってみた時のメモリ使用量なんかが実運用上では参照値になると思います。

まだ、プロセスやコンテナの動作と使用メモリとの関連を掴みきれてないので、追って調査してみたいと思います。コンテナのメモリとディスクの関連も。

なお、今回動かしたサービスの殆どはiscsiのPersistentVolumeに接続しています。このあたりの方法も消費リソースと関わっていそうですね。

Kubernetesってメモリ使うんだよなー、よし、各ノードに6G割り当てるか、とかやっていたのですが、今回の計測で今の所3Gでも大丈夫なことがわかったので、設定を変更しました。やはり適切な設定は適切な計測から、ですね。ちなみに、Kubernetesでpodを動かす時に、CPU使用率やメモリ使用量の上限などを設定できます。このあたりについてもおいおい見ていきたいと思います。