search

TritonDataCenter / rfe

Requests for Enhancement
Mozilla Public License 2.0
3 stars 4 forks source link

RFE #1 discussion #2

Open danmcd opened 7 years ago

danmcd commented 7 years ago

Okay! I put the stake in the ground, so now let's talk about RFE #1.

Two major classes of discussion:

1.) FRONT END & APIs.

I know little/nothing about Triton's APIs, etc. etc. I've used the JPC, but that's it. I wish to know what will be needed on this end to make things happen. I know what I want to have happen, but don't know how to do it.

2.) BACK END & ACTUAL IP ROUTING AND (optional?) TUNNELS

I know far more about the tools here, but am not sure of the precise requirements people wish. Dual redundancy? BGP? OSPF? Ooh, that reminds me, mention routing protocols in general.... 25475f2f45360d132f9132e92bfcbe6044912a24 done.

Interoperability is not a problem until we get to other-cloud connectivity. What is a problem is default algorithm selection. That will depend on the classic balancing act of performance and security. Though there are HW tricks one could bring to bear in both the CPU and in some 10GigE parts (at the cost of MORE development work).

danmcd commented 7 years ago

Added 15b033cf64b30f4a32a57646f5b10680babb17b7 which covers the possibility of a router object being a NAT to the Internet for Triton instances that otherwise can't reach it.

misterbisson commented 7 years ago

This router object may have some role in our efforts to provide services, or to enable Triton as a platform on which others can provide services. For that, we may need to route between fabric networks owned by different users. I imagine most of that will be dependent on RBACv2, but I wanted to raise it for consideration here as well.

danmcd commented 7 years ago

Added 6cb31ae2f1481cedcc0c10959ceae7cf811bdbe2 per your suggestion, @misterbisson.

danmcd commented 7 years ago

Folks interested here should also look at #4 as well.