Spearhead
/
rfd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

post rfd 10

This commit is contained in:
Marius Pana 2022-06-14 12:35:08 +03:00
parent aa10605c4c
commit f4a2db82b6
2 changed files with 20 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
README.md
View File

@ -45,6 +45,7 @@ formal writing that it has come to represent.)
| predraft | [RFD 7 Spearhead Cloud VM Consoles](./rfd/0007/README.md) |
| predraft | [RFD 8 Spearhead Cloud Billing updates](./rfd/0008/README.md) |
| predraft | [RFD 9 Spearhead Cloud Checkmk Monitoring](./rfd/0009/README.md) |
| draft | [RFD 10 Spearhead Cloud Checkmk Monitoring](./rfd/0010/README.md) |
## Contents of an RFD

64
rfd/0010/README.md
View File

@ -1,70 +1,44 @@
---
authors: Marius Pana <mp@spearhead.systems>
state: pre-draft
state: draft
---
# RFD 10 Spearhead Cloud Customer Portal feature updates
[Trixae](https://github.com/spearheadsys/sc-portal), our cloud customer portal, is in an MVP state: it offers minimum functionality but not much else. There are pieces of the software that also require some fine tuning in order for the product to become more usable, more user-firendly/intuitive.
[Trixae](https://github.com/spearheadsys/sc-portal), our cloud customer portal, is in an MVP state: it offers minimum functionality for general operations with cloud resources (provision, start, stop, etc.). There are pieces of the software that also require some fine tuning in order for the product to become more usable and user-firendly/intuitive.
# What problem is this solving?
We are trying to break our dependece on the existing customer portal (my.spearhead.cloud) which is based on theJoyent provided piranha codebase. This codebase is old, not very intuitive but most importantly we could not find developers/designes that would work with this codebase (based on angular v1) in order to update and maintain.
We are trying to break our dependece on the existing customer portal (my.spearhead.cloud) which is based on the Joyent provided piranha codebase. This codebase is old but more importantly we could not find developers/designers that would work with this codebase (based on angular v1) in order to update and maintain.
Our new portal will become the default and as such must offer a pleasant and stable experience.
# What are the principles and constraints on the design of the solution?
You should use this section to describe the first principles or other important decisions that constrain the problem. For example, a constraint on the design may be that we should be able to do an operation without downtime.
We have decided we would continue using Trixae for the forseeable future by adding new features, fixing existing issue/bugs and generally expanding it as requirements arise.
# How will users interact with these features?
Here, you should consider both operators, end users, and developers. You should consider not only how they'll verify that it's working correctly, but also how they'll verify if it's broken and what actions they should take from there.
Users will interact with this portal via their browser. Alternatively and for more advanced use cases, there is a full featured and mature API as well as command line interface.
What repositories are being changed, if known?
Operators may use the portal to troubleshoot/investigate issues or for our own tenants. Generally operators will; use the CLI/API's however if we have customers permissions and credentials, we may use this portal.
If it's known, a list of what git repositories are being changed as a result of this would be quite useful.
What public interfaces are changing?
What interfaces that users and operators are using and rely upon are changing? Note that when changing public interfaces we have to be extra careful to ensure that we don't break existing users and scripts.
What private interfaces are changing?
What interfaces that are private to the system are changing? Changing these interfaces may impact the system, but should not impact operators and users directly.
What is the upgrade impact?
For an existing install, what are the implications if anything is upgraded through the normal update mechanisms, e.g. platform reboot, sdcadm update, manta-adm update, etc. Are there any special steps that need to be taken or do certain updates need to happen together for this
What is the security impact?
What (untrusted) user input (including both data and code) will be used as part of the change? Which components will interact with that input? How will that input be validated and managed securely? What new operations are exposed and which privileges will they require (both system privileges and Triton privileges)? How would an attacker use the proposed facilities to escalate their privileges?
Once we implement this RFD, the portal will be fully functional meaning we are not missing major functionalities.
# What repositories are being changed
> Trixae MVP is in production at https://t.spearhead.systems
> we are now targeting a more featurefull version
>
> things we would like from Trixae
> * extremely simple to use
> *volumes
- show more details (such as ip and mount point)
- enable some form of pagination, the list can get big for large customers and unmanageable
The following repositories will be modified/changed to accomodate our proposed changes.
firewall
- enable some form of pagination, the list can get big for large customers and unmanageable
- filter by vm name (rules are attached to vms as far as I know)
machines
- enable some form of pagination, the list can get big for large customers and unmanageable
- add list of firewall rules
- add possibility to add new firewall rules (delete, etc.)
[sc-portal](http://github.com/spearheadsys/sc-portal) otherwise nown as Trixae.
dashboard
- introduce a new entry point, the default page, which is a dashboard containing
- different statistics and metrics such as
- usage trend
- number of running, stopoed, etc vms
- number of volumes
# What public interfaces are changing?
We are changing the UI of the customer portal. API and CLI continue to function as before.
# What is the upgrade impact?
For an existing install, we expect to git clone/pull the new resources, update configuration files and off we go. Downtime should be be minimal, requireing just a reboot of the service.
Because we can deploy multiple instances of the portal, we can bring up the new version and redirect trafic to the new once we are ready.