oxheadalpha / teztnets Goto Github PK

Just like the docker image, it'd be nice to also grab the link to the tarball of static binaries https://teztnets.xyz/mondaynet-about

PS: it is all there, but not obvious enough: the commit hash within octez is part of the docker tag, it could be made more obvious. Moreover:

• from tezos/tezos:master_254a9bdd_20220319194930
• One can make: https://gitlab.com/tezos/tezos/-/commit/254a9bdd
• and go click on the pipeline to find the static binaries job, click on it to get the artifact, 😅

https://github.com/oxheadalpha/teztnets/blob/main/.gitmodules#L3

https://github.com/oxheadalpha/teztnets/blob/main/.gitmodules#L6

https://github.com/oxheadalpha/teztnets/blob/main/.gitmodules#L9

It only works on mondaynet, but on granadanet I got the following preview:

     pulumi:pulumi:Stack                                                              teztnets-dev                                                         15 messages                                                                                        
 +   ├─ kubernetes:helm.sh/v2:Chart                                                   tezos-granadanet-2021-05-20t15:00:00z                    create                                                                                                         
 +   │  ├─ kubernetes:core/v1:Service                                                 tezos-granadanet-2021-05-20t15:00:00z/tezos-node         create      
 +   │  ├─ kubernetes:core/v1:Service                                                 tezos-granadanet-2021-05-20t15:00:00z/tezos-node-rpc     create      

It's probably because the split function expects the time to be 00.

I'll be hardcoding granadanet namespace for now, but I would prefer not to.

Dear Team,

as a Tezos "heavy user" the integrity and stability of the network is imperative to our operations. Protocol upgrades are the most exciting and also most dangerous events for our business. The days of protocol transition are often ones of sweat and staring at the node hoping everything goes smooth. What can be done to ease this experience?

Making the participation more accessable to the Tezos ecosystem with teztnets.xyz is great we at StakeNow fully embrace and is in our opinion the first and most important step to onboard more testers for broader test coverage and test networks closer to reality.

At Tezos we currently have two node implementations with Octez and TezEdge where the latter is only used by specialist teams with specific needs. The shell implementation is rather young but incredible!

We think that a network with a wider variaty of node implementations (ideally 50/50) would be extremely benificial for the robustness of the network. We have seen round >60 in the current Tenderbake testnet due to node crashes through TPS tests. With the 1/3 requirement of nodes to be responsive for the chain to progress a set of TezEdge baker would have come handy!

Feature Request:
Please include the instructions for TezEdge bakers and nodes into the descriptions and also try to be a good example in running them by yourself. The first "retail users (bakers)" do reveal the child diseases of the implementation which will help the developers and eventually the network.
In our opinion the core protocol developers should only inject a new proposal if at least the two implementations of TezEdge and Octez are successfully tested in the test networks. Please help us to bring this debate to the table and get into contact with us about it!

Best regards
Your StakeNow Team

All teztnets should bake using KMS instead of a key kept in a k8s secret. This should be pulumized.

Flag testnets are "long-running" or "short running".

For short running testnets, generate a new name and reactivate a new chain from scratch at every release.

release.py loops through the teztnets folders and publishes one teztnet per found folder. However, sometimes we comment out the relevant instantiation of the pulumi resource in index.ts

index.ts should dynamically instantiate component resources based on which folders are here. it will force us to actually destroy the folder when we destroy a teztnet.

Luke Youngblood asked that tez be sent to a couple of his addresses on granadanet. I ssh'd into the node and found that no secret key exists for the tqfree account and hence I couldn't send tez from it.

The reason is due to code in tezos-k8s that imports for a baker only the secret key it needs for baking. So any other account that is not a bootstrap baker account only gets its public key imported by a node.

The way I got around this was by finding the secret key in the k8s secret config and importing it into the node. Then sent the tez.

making a release after a testnet already exists causes issues with pulumi: it launches the activate job again, but since the chain is already activated, it fails,and subsequent deployments never run.

A good enough solution is to comment out the activation session of every teztnet yaml after it's already activated.

Another solution would be to make tezos-k8s "silently fail" to activate when it's observed that the block number is bigger than 1.

But I'm not too sure about the latter as it's not declarative. Looking for opinions here....

If one record for bootstrap peers goes away, the baker gets stuck in wait_for_dns init container. We should not wait for dns in this case.

Today we just have the docker tag, we need the git tag (extracted from docker tag) and a link to gitlab.

A regular AWS user (non-root) of the account on which this pulumi deployment is done should not be able to transfer any of the testnets baking account token to a third address, unless they are part of a special IAM group. This unprivileged user still has enough access to do all other devops tasks necessary to maintain the cluster (deploy k8s manifests, run k9s, restart pods, open shell in pods etc)

It means:

• they should not be able to access the baking key directly (k8s secret), otherwise they can just import it to another wallet and transfer the funds out
• they should not be able to open a shell into the remote signer container and read the key (otherwise they can do the above)
• they should not be able to sign a transfer operation using the remote signer http interface (signing a bake/endorse operation would be ok, though). The remote signer can be launched with special arguments that allow this (this would require tezos-k8s patch)
• maybe other attack vectors exist

This requires mapping IAM permissions to role-based access control of k9s.

All of this should be pulumized. So hypothetically, we would be able to destroy and recreate the entire infrastructure, and this unprivileged user would still not be able to do any of the above.

buy pulumi
aws service account key
aws service account secret
pulumi service account

Chain activation results in:

Error: Json_encoding.Unexpected_field("michelson_maximum_type_size")

Param is now hardcoded: https://gitlab.com/tezos/tezos/-/merge_requests/3308

As a protocol developer, I want to get a testnet running for my team's new protocol version so that a real-world publically accessible testnet can work allowing other teams to test against it and give me feedback and bug reports.

Proposed Solution

Define a process where a PR is created that adds the appropriate yaml that defines the new network, including docker image, constants and so forth.

The process to decommission a testnet must also be defined (should be as easy as removing the relevant testnet yaml declarations).

Solution: do not define other bootstrap peers in metadata.yaml, but actually in values.yaml (where it belongs)

teztnets is now hosting a faucet, but it is only accessible with tunneling.

Implement the necessary plumbing so the dailynet faucet link in https://teztnets.xyz/#dailynet works.

Should also clean up the chain values.yaml files to make it easier for users to see how to specify their own chain parameters.

For example:

{ "name": "mondaynet",
  "description": "a testnets created from scratch every monday with the most recent codebase from tezos master branch"
}

Display this field in the release notes.

We made changes to the rollup node values f58b3cf and the actdivation job did not clear out and restart causing us to manually have to delete and create a new job on the cluster.

Expected functionality should be if a job is dependent on a value it should be deleted and restarted to prevent this manual intervention.

As a first step in the KMS project, let's separate bakers and signers for all the teztnets.

It should be as simple as doing this: https://github.com/oxheadalpha/tezos-k8s/blob/master/charts/tezos/values.yaml#L199-L204

Signers are present but idle. Configure the bakers to use them.