Create a policy page and move instructions to join the infra #125
Conversation
mkowalski
force-pushed
the
testbed-policy
branch
6 times, most recently
from
b97dd62
to
76480bf
Compare
mkowalski
force-pushed
the
testbed-policy
branch
4 times, most recently
from
052cb5f
to
f825935
Compare
mkowalski
changed the title
| 3. Allow the SCIONLab management institution to install, remove and update SCIONLab related software as needed for the operation and maintenance of the network. | ||
| 4. Work with the SCIONLab management institution to solve any firewall and tunneling issues that may arise during the installation, configuration and operation of the SCIONLab node(s). | ||
| 5. Provide the name, email and telephone information of an easily and quickly reachable site-specific operator who will be the main contact whenever issues arise with the local SCIONLab node(s). A backup operator, while not required, is highly encouraged. Operator email addresses must belong to the institution. All local operators will be required to join and regularly monitor an SCIONLab community mailing list and are required to respond to requests from the testbed management institution in a reasonable time, but no more than 3 working days. | ||
| 6. Ensure that the machine has limited logins beyond the SCIONLab account. A local operator account is highly encouraged, but general user accounts should not be present on the SCIONLab node. In addition, only SCIONLab-related software should be allowed to run on the machine. |
There was a problem hiding this comment.
Is this actually true? Don't we want to allow e.g. active researchers that do stuff with SCIONLab to have access to the machines? (Maybe not, because researchers mess things up :D but if not, then who exactly is the target group for joining the infra?)
There was a problem hiding this comment.
This is very true. If they want to play with the machine, they should be using user AS. I do not trust any of this dudes to do anything inside this machine and not breaking stuff
There was a problem hiding this comment.
Okay, but:
- we say "[blablabla] you are committed to do research with SCION, and using user ASes is not enough for your plans" in instructions.md
- we say "Connecting to the testbed for the sake of being connected is a violation of the current policies" in policy.md
So that sounds to me like we want people to join the infra when they want to do fancy research with it.
And then we say "limited logins beyond the SCIONLab account" here, so that they cannot do fancy research with it :D
So, it seems to me that these three things together strongly limit who is supposed to be joining the infra and why. The only use case that I can come up with while satisfying all three is just something like "we really really want a local attachment point". Is this actually the only use case? If no, please tell me about another one :D And if yes, should we just say that explicitly at the beginning of instructions.md?
There was a problem hiding this comment.
Okay, let me give you a specific example. We have a SCIONLab node somewhere in Austria (I believe TU Vienna), where some "Charlie dude" logs into the machine and changes configuration of the SCION services to something super dumb, making the services fail hard during the start-up. As this is not transparent for the rest of the network, I do not want him to be allowed to misconfigure stuff. By this I mean the configuration of the infrastructure should be stable and deterministic and someone ssh-ing and modifying random files contradicts both these points.
There was a problem hiding this comment.
Let me give you a second example. We used to have a node in Israel which was not used by anyone for an unknown amount of time. Once this node has died (i.e. went no-contact without anybody informing us) it took these guys more than 3 months to reply to Juan's email. I need a mechanism to enforce a strong reaction in these cases as I do not want SCIONLab to become a graveyard of machines which used to work once and nothing more.
| 5. Provide the name, email and telephone information of an easily and quickly reachable site-specific operator who will be the main contact whenever issues arise with the local SCIONLab node(s). A backup operator, while not required, is highly encouraged. Operator email addresses must belong to the institution. All local operators will be required to join and regularly monitor an SCIONLab community mailing list and are required to respond to requests from the testbed management institution in a reasonable time, but no more than 3 working days. | ||
| 6. Ensure that the machine has limited logins beyond the SCIONLab account. A local operator account is highly encouraged, but general user accounts should not be present on the SCIONLab node. In addition, only SCIONLab-related software should be allowed to run on the machine. | ||
| 7. The machine may be a dedicated physical box or a virtual machine with a publicly routable IP address (i.e., should not be behind a NAT). The local operators should ensure that if the machine has usage limits or other restrictions (for example VMs on cloud services), those will not interfere with proper testbed operation. | ||
| 8. In case more than one machine is being provided by the institution, it is allowed if only one of them has a publicly routable IP address whereas the others use private static IP. |
There was a problem hiding this comment.
This is to cover the following use case
- multi-host AS
- border router has a public static IP for the uplink connectivity
- services inside AS talk with each other using static private IPs (because public are not needed as long as inside-AS connectivity works)
There was a problem hiding this comment.
what about having having multiple border routers for uplink?
There was a problem hiding this comment.
This is a valid scenario, we should then write something closer to "machines hosting border routers must have a public static IPv4 address"
| 11. Suggested Location: SCIONLab node should reside in a machine room in a rack. | ||
| 12. Suggested Network Connectivity: There is no minimum bandwidth requirement for SCIONLab nodes; however, higher network speeds are both recommended and desirable. | ||
| 13. Participating institutions may disconnect from the testbed upon giving appropriate (at least 24 hours) notice to the SCIONLab testbed management institution. The same policy applies if the participating institution wishes to turn off the machine for maintenance and/or hardware upgrades. Early notification will allow the testbed management institution to take any actions necessary to prevent unnecessary disruption of service to the testbed. | ||
| 14. We strongly discourage and will not accept requests to join the SCIONLab testbed if there is no intention to use it for productive research. Connecting to the testbed for the sake of being connected is a violation of the current policies. |
There was a problem hiding this comment.
(does this mean that like half of our nodes are in violation of the current policies? :D)
There was a problem hiding this comment.
Just to make it clear, this does not mean we are removing half of the nodes from day 1. This only means once we have a node which obviously misbehaves and no one reacts in a reasonable amount of time, we have a CYA to throw at them and enforce an action (this being either cooperation or removal).
|
General issue: it should be explicitly mentioned somewhere at the beginning of |
I believe this is we are trying to implicitly push, but maybe we should emphasize it even more. Also you know my view... I still stand strong on the opinion that whoever claims SCIONLab is ready to run in a federated-responsability model has not seen a life outside of his office. Currently people outside of our office (excluding Anapaya) do not have a knowledge how to run SCION infrastructure, therefore we have 3 options
While (1) is something we are not obviously doing at the moment, I believe a mixed model of (2) and (3) is the way to go right now. Mixed meaning SCIONLab Infrastructure strictly follows (2) and SCIONLab User ASes follow (3). |
mkowalski
force-pushed
the
testbed-policy
branch
from
f825935
to
62c4744
Compare
There was a problem hiding this comment.
Reviewable status: 0 of 3 files reviewed, 8 unresolved discussions (waiting on @AnotherKamila and @FR4NK-W)
content/join/policy.md, line 11 at r1 (raw file):
Previously, AnotherKamila (Kamila Součková) wrote…
English nitpick:
s/an SCIONLab/a SCIONLab/
Done.
content/join/policy.md, line 13 at r1 (raw file):
Previously, AnotherKamila (Kamila Součková) wrote…
English nitpick: SCIONLab-related (missing dash)
Done.
content/join/policy.md, line 15 at r1 (raw file):
Previously, AnotherKamila (Kamila Součková) wrote…
English nitpick: s/an SCIONLab/a SCIONLab/
(Or maybe actually the, not a, because we mean a specific one? Do we?)
Done.
content/join/instructions.md, line 18 at r1 (raw file):
Previously, AnotherKamila (Kamila Součková) wrote…
s,policy.md,policy.html,
s,telling,letting us know that,
Done.
content/join/instructions.md, line 19 at r1 (raw file):
Previously, AnotherKamila (Kamila Součková) wrote…
Is this a bad copy-pasta? seems to be here twice now
Done.
There was a problem hiding this comment.
Reviewed 1 of 3 files at r1, 2 of 2 files at r2.
Reviewable status: all files reviewed, 8 unresolved discussions (waiting on @AnotherKamila)
content/join/policy.md, line 18 at r1 (raw file):
In case more than one machine is being provided by the institution, it is allowed if only one of them has a publicly routable IP address whereas the others use private static IP.
--> In case more than one machine is being provided by the institution, at least one of them needs to have a publicly routable IP address. The others can use private static IPs.
Closes: #111
This change is