The engineering from eosnetworkfoundation

DNS Root Migration

Prepare for and participate in the DNS root migration of some of our key domains.

Create Telegram Service Account

Following engineering issue 49, this ticket is to create an Automation service account on Telegram. The Automation service account will then be used to create group chats or channels, and to integrate bots in our environment. Using a service account divorces the ENF infrastructure from an employee account, reducing attacks targeted at employees and making it easier to transition infrastructure if or when employees move on. This requires a private phone number that can receive SMS messages, which is currently...challenging.

eos-evm issue 602 - Funnel EVM Health Checks into CloudWatch
engineering issue 48 - Collaborate with Operations on Unified Dashboarding Solution
engineering issue 49 - Create Bot to Alert via IM on Specific Metrics
eos-evm issue 603 - SMS Alerting for EVM Infrastructure Health Checks
engineering issue 65 - Email Alerting for EVM Infrastructure Health Checks
telegram-bot issue 1 - Open-Source This Repo
engineering issue 57 - Create Telegram Service Account
engineering issue 58 - Create EVM Testnet Alert Channel Using Telegram Service Account
engineering issue 64 - Create EVM Mainnet Alert Channel Using Telegram Service Account
engineering issue 66 - Fix EVM CloudWatch Alerts
telegram-bot issue 2 - Human-Friendly Alerts
engineering issue 71 - EVM Alerts for APAC Infrastructure
telegram-bot issue 3 - Alert Bot Maintainer via Telegram on Errors

Add Clang to CI/CD builds

[transferred from legacy agenda on behalf of @linh2931 ]

(Should we) add Clang build (compile only) to CICD?

Example of issue with status quo: Lambda capture of structured binding compiles in GCC but not Clang in ‘C++17’ mode. Example: AntelopeIO/leap#703

Versioned HTTP APIs

Ratify the discussion issue process

Should we ratify the new discussion issue process?

The old meeting was not creating good outcomes and I proposed a new process. I hope to document that process in a living way as it evolves and this is the first iteration of that.

The PR is here: #29

Product Ownership for Code Documentation

In looking at running Doxygen as part of Leap CI, and larger discussion came up. Spoke to DevRel and they are focused on developers using EOS not developers of EOS.

Who is the audience/consumer
- Engineers writing code for our own products
- ~~Developers using EOS~~
Who is the product owner
- ENF Engineering
- ~~Devrel~~

The product owner determines the requirements, and helps inform the priority of the work.

What parts of Leap code do we want to run Doxygen on?
How should we expose the documentation from Doxygen?
- host on web server?
- include with binary package?
- include in git repository?
Do we want any checks for documentation as part of our CI build?
- require certain level of coverage via coverxygen or similar

Research and test Open Federated Identity Providers

Follow-on work from #12

- [ ] Evaluate the provider(s) available
Alpha or beta test provider
Review results with stakeholders
Write followup issues as needed

Upgrade to C++20

[Transferred from legacy agenda on behalf of @greg7mdp and @ScottBailey]

(Should we) consider switching to -std=c++20 for leap and appbase? (@greg7mdp)

It’s 2023, can we have FULL C++20 support? If now isn’t the right time, when is? (@ScottBailey)

Publish Onboarding Documentation

When I joined the ENF, I took notes on many of the steps I took to setup my personal Linux machine for work in Joplin. @larryk85 scheduled a meeting to discuss on-boarding, so I figured I should publish what I have somewhere before that meeting. This ticket tracks that work.

I published the following for this ticket.

Computer Setup - options for keeping your work and personal life separate on your computer
Docker - docker reference and quick-start guide
Tool Install Guilde - install common tooling on your machine
Ubuntu Virtual Machine Setup Guide - setup an Ubuntu virtual machine you can use for testing, and quickly restore to known-good states

Verify Domain Ownership for Google Search Console

I have been asked to add a TXT record to the eosnetwork.com DNS to verify our ownership so Marketing can use Google Search Console.

google-site-verification=SBDxnXYx5--T6VszuLGvuqJJywEcU5rf2iF5WczEIiM

Redefining Support SLA

DNS Record - Authorize Marketing Tool

Marketing and Communications would like the following DNS record entered for eosnetwork.com to authorize one of their tools to send emails from [email protected].

NAME scph0823._domainkey
TYPE TXT
VALUE v=DKIM1; k=rsa; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4tXAIvUiae0mMLL2FE4V5pxehsZ83NIAp1KrIAFGaUZSXxTYod/xk8NVHvM++yY1vkXA7DC5hwawSV1feb1QzWmFUcKu7x8QjT5tIVoxbZJKHQb+rRO7zkGKKd1D9Cp444uG9OS9tFMuUrjpTTt7bRi6i0OA1D9h8042NXq+CvwIDAQAB

Do the thing.

Automated Community Sentiment Analysis

placeholder for @brandenespinoza or @kj4ezj to fill in more information for

Dev Rel Migration

Tasks

Beta Give feedback

DNS Migration - learn.eosnetwork.com #59

Infrastructure
Tear Down Old Documentation Infrastructure #56

Infrastructure
404 on Course Episode Pages devhub#22

Infrastructure bug
Options

DUNE CI/CD on Windows and macOS

It would be great if DUNES had CI/CD support for Windows and OSX (both x86 and arm).

Currently, github doesn't seem to support nested VMs.

I believe this means we need self-hosted runners.

Cloud Hosted Performance Box

Summary

Recent performance run show evidence of performance issues. The TPS is varying between both versions of leap, and the type of load (transfer action, vs read only). To understand the scope of the issue and help debug we need a single big iron host. An isolated host is needed to get repeatable results.

Work Request

OCI employees needs to be able to log into a host, compile and setup leap, and run performance tests.

Host Requirements

Large host 64Gb and 16core should do 600 Gb SSD.

Collaborate with Operations on Unified Dashboarding Solution

As part of an epic for a unified metrics and alerting system around EVM infrastructure, this ticket is to collaborate with Operations to survey their existing ability to dashboard and alert on metrics in order to prevent fragmentation within the organization as metrics and alerting are built out for Engineering. Their solutions may or may not meet Engineering needs, but we should prevent fragmentation where possible.

Background

Currently, all EOS Network Foundation (ENF) infrastructure exists at eosnetwork.com or one of its sub-domains. This is ideal for (external) customer-facing services such as learn.eosnetwork.com.

Problem

Using the primary, customer-facing web real estate at eosnetwork.com for internal services, developer work, and engineering testing creates unnecessary risk to our outward-facing properties and currently involves friction. While we have plans to eliminate the friction, the risk will remain.

There are a number of other domains marketing has picked up to protect our brand and they are more than happy to let engineers use some of them, but they have asked that their department approve changes made to these domains in advance. This is a perfectly reasonable request. Automation is grateful to work with Marketing and we are certain requests will be approved quickly. However, this is still friction.

Solution

Automation is requesting permission to purchase one or two domain names to be used exclusively for inward-facing services, developer work, and engineers. These domains would be frictionless in the sense that Automation and Engineering would have ownership over them, be able to provision resources for internal projects without risk to external customer-facing resources, and provision resources without approval from other departments. Automation has a shortlist of domain names we have confirmed are available to use for this purpose but we have intentionally excluded them from this ticket to protect their availability. The list is available via IM or email upon request.

The cost of these domains would be $20-$40 per year per domain name.

Quick Fix or Full Solution for ABI Type Issue in CDT 4.0

AntelopeIO/cdt#198

AWS Account Federation

Background

As discussed in issue 5, both Amazon Web Services (AWS) best practices and Google Cloud Platform (GCP) best practices recommend that any organization distribute their cloud infrastructure among multiple accounts, to use AWS terminology. The EOS Network Foundation (ENF) is now doing this.

Problem

ENF cloud infrastructure administrators currently juggle multiple logins to access the different AWS accounts in use. While administrators of the ENF organization do retain absolute control over all accounts and resources, there is not a clear pattern for anyone to use their existing credentials to access resources in new accounts. This creates friction for internal customers as well as unnecessary complexity and opacity for administrators. Relying on humans to secure multiple sets of credentials also increases risk exposure.

Solution

The EOS Network Foundation needs to implement federated logins within our Amazon Web Services organization. We can accomplish this with our existing resources by federating our Google Workspace (Gsuite) accounts into the AWS IAM identity center as described here and here. This will empower cloud administrators to use the AWS IAM Identity Center to grant individuals and teams access to cloud resources across the organization based on need using identity and access management (IAM). This also simplifies off-boarding by implicitly revoking access to AWS resources when access to Google resources (Drive, Gmail, GCP, etc.) are revoked.

This type of user access will be portable across the organization no matter how many AWS accounts are created for different systems. One or more select organization administrators would still be required to maintain a login detached from Google to the management account, but administrators logging in using Federation would have visibility into the whole organization by default as defined by our IAM policy.

Document Engineering Internal Decision-Making Process

We are going to start making decisions in a more organized fashion. We need to first decide and vote on how consensus is achieved.

Notify marketing when a release takes place for a signficant repo

As Product, I don't want to manually message Marketing and Comms teams to trigger a series of Social Media activities when a new release takes place. Because Github and Telegram will continue to be the tools we use for the foreseeable future, we should automate this process and consider whether we wish to connect this automation to additional tooling for social pushes.

Acceptance Criteria

When a new release takes place for the following repos, send a Telegram message to the MarCom general chat with a link to the releases notes in Github
- Leap
- CDT
- DUNE
- reference contracts

Draft Cloud Resource Organization Hierarchy

While working on Developer Relations issue 80, I found there is not currently an organized layout of organizational units (OUs) and accounts in Amazon Web Services (AWS). These terms correspond to folders and projects in Google Cloud Platform (GCP), respectively, and we likely don't have a strategy for organizing resources there either. I brought up this concern and was asked by @ericpassmore to come up with such a strategy. This ticket tracks that subset of work.

Tear Down Old Documentation Infrastructure

In engineering issue 55, Automation collaborated with Developer Relations to migrate the docs.eosnetwork.com infrastructure to a new AWS account (docs-prod), culminating in a "DNS switcharoo." Once we are certain the new DNS records have propagated worldwide, Automation will tear down the old documentation infrastructure.

eosnetworkfoundation / engineering Goto Github PK

engineering's People

Contributors

Watchers

engineering's Issues

See Also

See Also

See Also

See Also

See Also

Tasks

Summary

Work Request

Host Requirements

See Also

Background

Problem

Solution

Background

Problem

Solution

See Also

See Also

See Also

See Also

See Also

Tasks

Recommend Projects

Recommend Topics

Recommend Org