ignw / mozilla-rust-sdk Goto Github PK

To measure our work on realistic deployed configurations we should collect information about:

• target linux distribution
• target machine class
• any network configuration that may impact throughput or latency to Google's services

Google has written several open source libraries in various programming languages that perform service account authentication over gRPC, but the documentation available on grpc.io is quite high-level. If they have additional documentation available to guide implementation of service account auth, it will speed up the understanding of the implementations in java, golang, etc... and help guide our implementation

Create a GCP project for the Ferrous team to use as a development environment and grant "Project Owner" rights to Tyler and James.

Neither Item nor Error are associated with core::future::future::Future leading to compile failures with later versions of futures

creating this issue for tracking specifics around the attempts to get something working with tower-grpc

In developing our testing strategy, we should work toward supporting a testing strategy that will work well with Mozilla's plans for their Push service. Determine if they have any special needs around the following:

• test infrastructure that runs on different operating systems or network configurations than how they want Push to be deployed
• test infrastructure that does not have easy access to the Google APIs
• test infrastructure that needs to perform API configuration before, during, or after use

The Google gRPC APIs require authentication tokens to be passed along when establishing gRPC connections and along with each request. Determine if Mozilla has any restrictions around the information required to create these tokens

Mozilla has mentioned that they prefer to use an API built atop tower-grpc, an asynchronous networking stack that is currently under active development and not recommended for production usage.

• gather information about why the authors consider the library unfinished and their roadmap
• gather information about existing plans to support Google Service Accounts in tower

Create an initial CI pipeline for later use by development team. Initial pipeline should probably not actually do anything, but rather be set up to enable quick addition of:

• Unit Tests
• Linting
• Integration Tests
• Smoke Tests
• Nightly Code Drops?
• Release Candidate Delivery
• etc.

Looking for comments from Dev team on what would be useful here.

Here is a report on the metadata of the dependencies used by this crate:

james@archx1c6g ➜  mozilla-rust-sdk git:(master) ✗ cargo license
Apache-2.0 (3): grpcio-sys, grpcio, clang-sys
Apache-2.0|MIT (41): arc-swap, num-integer, chrono, time, unicode-xid, peeking_take_while, rand_core, thread_local, rand_core, log, rust-argon2, backtrace, regex-syntax, term, glob, proc-macro2, base64, cc, winapi, futures, backtrace-sys, regex, version_check, crossbeam, cmake, autocfg, rustc-demangle, cfg-if, cexpr, num-traits, bitflags, nodrop, arrayvec, shlex, pkg-config, winapi-i686-pc-windows-gnu, lazy_static, crossbeam-utils, rand_os, winapi-x86_64-pc-windows-gnu, fxhash
Apache-2.0|MIT|MPL-2.0 (4): slog-scope, slog-stdlog, slog-term, slog-async
BSD-2-Clause (2): arrayref, cloudabi
BSD-3-Clause (1): bindgen
CC0-1.0 (1): constant_time_eq
ISC (2): rdrand, libloading
MIT (9): take_mut, redox_syscall, atty, protobuf, nom, synstructure, which, redox_users, blake2b_simd
MIT OR Apache-2.0 (7): syn, failure_derive, log, libc, failure, dirs, quote
MIT|Unlicense (5): same-file, memchr, walkdir, winapi-util, aho-corasick
MPL-2.0 OR MIT OR Apache-2.0 (1): slog
N/A (3): googleapis-raw, googleapis, fuchsia-cprng
Unlicense OR MIT (1): byteorder

Based on this, I believe we should be fine to select the Rust standard license of dual MIT + Apache 2.0 as discussed in the last meeting. If we get approval of this from Mozilla (CC @pjenvey @ThomasMoz), we can add the appropriate licenses to the repository, Cargo.toml, and add a notice in the README.

Create a Bi-Weekly Status meeting that includes the following people:

Ferrous: Tyler, James
IGNW: John W., Erin S.
Google: Michael, Rahul, John Loftis
Mozilla (as optional attendees): Travis, Habib, Phil, Thomas

Make sure to make the meeting editable by attendees so the Google team can invite additional folks on their side if needed.

To help focus feature development, we need to look at how Mozilla is currently utilizing Dynamo in their Push service and list all of the functionality being used, and map that to prospective BigTable API calls.

The Mozilla Push related repos:
https://github.com/mozilla-services/autopush-rs
https://github.com/mozilla-services/autopush

Please create a git repo for the project team from Ferrous to use and grant access to:
jamesmunns
spacejam (Tyler)