Use go-native blazer library as a B2 SDK

Aperta
  • Qualcosa non va?
#25 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
go
Ambito
api, backend

Direzione di ricerca

The issue names no files or tests and proposes using this library as a Terraform/OpenTofu provider’s B2 SDK. Start by reading the library’s existing API and comparing it with the provider’s required B2 operations, especially notification rules. Done would require the needed functionality and a maintained integration, but the issue does not define a concrete scope or acceptance criteria.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

As https://github.com/Backblaze/blazer is successfully used by the tool like https://github.com/restic/restic since 2017, it looks like it is mature enough to be used as a B2 SDK library in this provider. Using python SDK from go programming language has many drawbacks that using go-native library would solve.

Pros:

  1. No need to embed the whole python interpreter, which can significantly increase the boostrap time. Terraform/OpenTofu providers are compiled to executables that the main process executes, sometimes many times in one plan/apply. Each time, the python bindings must be unpacked and executed multiple times as a separate process. This is slow, which we can see in ACC tests that take few minutes with 4 concurrent processes.
  2. Possibility to cross-compile every version on just Linux machine, so we can serve more architectures and operating systems without much effort. Go produces fully static binaries, so that provider would work on older versions of macOS and Windows - not like now. On Linux, we use staticx to make the provider statically linked with glibc which causes another problems (e.g. with rpath).
  3. Reduced CI time (see point 1)
  4. Blazer quality could benefit, as this provider would use most of the functionalities provided by blazer, in opposite to tools like restic.
  5. Less error-prone as mapping outputs from the python lib to the golang was causing most of the problems in the past. When keeping everything in golang, we can benefit from having it strongly typed, thus problems detected during the compilation time rather than runtime.

Cons:

  1. There are some missing functionalities in blazer that need to be implemented, e.g. notification rules. Also, it would have to be properly maintained and quite up-to-date in order to use new features (and bug fixes) in the future. Not really a cons tbh :)

BR/ Maciej

Lingua principale
Go
Stelle
66
Fork
18
Merge medio
1g 10h
PR unite (30g)
132

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Backblaze/blazer

Tutte le issue di Backblaze/blazer

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.