GithubHelp home page GithubHelp logo

sandialabs / sceptre-phenix Goto Github PK

View Code? Open in Web Editor NEW
16.0 7.0 23.0 13.81 MB

phenix is an orchestration tool and GUI for Sandia's minimega platform

Home Page: https://sandialabs.github.io/sceptre-docs/

License: GNU General Public License v3.0

Makefile 0.10% Shell 0.19% Dockerfile 0.14% Go 15.83% Batchfile 0.01% API Blueprint 0.40% CSS 1.31% JavaScript 75.74% HTML 0.69% Python 0.02% Vue 5.57% PowerShell 0.01%
scr-2646 snl-applications snl-cyber-sec snl-os-sys-software

sceptre-phenix's Introduction

phenix status Docker Cloud Automated build Docker Package Build Status

Welcome to phenix!

Building

Local build

To build locally, you will need Golang v1.18, Node v14.2, Yarn 1.22, and Protoc 3.14 installed.

Once installed (if not already), simply run:

make bin/phenix

If you don't want to install Golang and/or Node locally, you can also use Docker to build phenix (assuming you have Docker installed). Simply run ./hack/build/docker-build.sh and once built, the phenix binary will be available at bin/phenix. Run ./hack/build/docker-build.sh -h for usage details.

Docker build

Docker is the recommended way to build and deploy phenix.

The Docker image is updated automatically each time a commit is pushed to the main branch. To pull the latest image:

docker pull ghcr.io/sandialabs/sceptre-phenix/phenix:main

NOTE: currently the main image available on GHCR defaults to having UI authentication disabled. If you want to enable authentication, you'll need to build the image yourself, setting the PHENIX_WEB_AUTH=enabled Docker build argument. See issue #4 for additional details.

Using

Please see the documentation at https://phenix.sceptre.dev for phenix usage documentation.

Git Workflow Support

phenix can now support a git workflow. The following assumes an intermediary (e.g., a GitLab runner) exists to react to git push events.

The first example cURL command below should be run for each phenix topology or scenario file present in the repository. These should be run prior to the Workflow Apply request being executed.

Once all the phenix topology and scenario files have been added/updated, the phenix workflow config file (likely to be a hidden file in the root of the repository named .phenix.yml) should be applied. Applying the phenix workflow config file will trigger existing experiments to be updated and restarted, depending on settings within the workflow config file.

Optional tags can be passed as URL querries when the workflow config is applied. These tags are stored as a string key1=value1,key2=value2.

Add/Update Topology or Scenario Config

curl -XPOST -H "Content-Type: application/x-yaml" \
  --data-binary @{/path/to/config/file.yml} \
  http://localhost:3000/api/v1/workflow/configs/{branch name}

Apply phenix Workflow Config

curl -XPOST -H "Content-Type: application/x-yaml" \
  --data-binary @{/path/to/config/file.yml} \
  http://localhost:3000/api/v1/workflow/apply/{branch name}[?tag=key1=value1&tag=key2=value2]

phenix Workflow Config File Documentation

Below is an example phenix workflow config file.

apiVersion: phenix.sandia.gov/v0
kind: Workflow
metadata: {}
spec:
  auto:
    create: {{BRANCH_NAME}}-<string>
    update: <bool>  # defaults to true
    restart: <bool> # defaults to true
  topology: {{BRANCH_NAME}}-<string>
  scenario: {{BRANCH_NAME}}-<string>
  vlans:
    <alias>: <int>
  schedules:
    <vm>: <string>
  • auto - this group of settings is used to determine what events happen automatically when the workflow config is applied.
    • create - if set, this string will be used as the name of the new experiment to automatically be created for the current branch if one does not already exist. Omit this setting to prevent an experiment from automatically being created for the current branch.
    • update - if true (the default), an experiment for the current branch will be updated with its topology and scenario (if it has one). If the experiment is currently running, it will only be updated if auto.restart is also true.
    • restart - if true (the default), a running experiment for the current branch will be stopped, updated, and restarted when the workflow config is applied to phenix. If the existing experiment is already stopped, or a new experiment is created, it will be started. This setting has no affect if auto.update is disabled and an experiment exists for the current branch.
  • topology - the name of the topology config to use for the experiment. Variable substation will be applied to the config name. This setting can be changed to force an existing experiment for the current branch to use a different topology.
  • scenario - the name of the scenario config to use for the experiment. Variable substation will be applied to the config name. This setting can be changed to force an existing experiment for the current branch to use a different scenario.
  • vlans - a map of VLAN alias to VLAN IDs to apply to the experiment for the current branch. This setting has no affect if auto.update is disabled, or if auto.restart is disabled and the experiment for the current branch is running.
  • schedules - a map of VM hostnames to cluster hosts to apply to the experiment for the current branch. This setting has no affect if auto.update is disabled, or if auto.restart is disabled and the experiment for the current branch is running.

sceptre-phenix's People

Contributors

activeshadow avatar causand22 avatar cmulk avatar dnkcom avatar eric-c-wood avatar ghostofgoes avatar glattercj avatar jacdavi avatar mgaliar avatar mkunz7 avatar nblair2 avatar zach-r-long avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

sceptre-phenix's Issues

[UI] UnSelect All Checkbox Only Works When All Table Items Are Selected


Originally created by @eric-c-wood on Fri, 16 Apr 2021 16:26:42 GMT


Describe your environment

minimega version: 2.7
Linux distro/version: Ubuntu 20.04.1 LTS/5.8.0-38-generic
Go compiler version:1.14.2
VM types:kvm

Describe the bug

In the running experiment view, the "Select/Unselect All" checkbox fails to unselect all items if all items are not already selected.

To Reproduce
Steps to reproduce the behavior:

  1. From the running experiment view, select all VMs by clicking the "Select/Unselect All" checkbox.
  2. Unselect one VM
  3. Uncheck the "Select/Unselect All" checkbox
  4. All items are incorrectly selected

Expected behavior

When the ""Select/Unselect All" is checked, all table items/VMs are selected. When the "Select/Unselect All" is unchecked, all table items/VMs are unselected.

[UI] Enhancement Extend VM Search Fields

Describe your feature
The current VM search only searches for a VM by name. It would be nice to extend the search function to able to ask the following questions/queries:

  1. Find all VMs in a specific state (running, stopped, shutdown, etc..)
  2. Find all VMs that are currently capturing packets
  3. Find all VMs that belong to a specific subnet (192.168.20.1/30, 192.168.3.1/20, etc..)
  4. Find all VMs that are running on a specific host
  5. Find all VMs with specific tags/metadata.

Search criteria should be able to be combined with verbose Boolean operators such as "and,or,etc.." and have a default Boolean operator when not explicitly specified.

Feature Details
Stage of Experiment when feature is active: (Creation, Start, Post Start, Running, Stop, Delete)
stage: Running and Stopped. For a stopped experiment questions 1 and 2 will not apply. For all queries, it might be necessary to wait some period of time before sending the query to the server to avoid flooding the server with incomplete queries.

Where should feature be visible (current phenix tab and general location or propose a new tab, or not visible)
view: The query can be ran from the current search bars on both the running and stopped experiment views.

Expected behavior
The running and stopped views will show only the VMs matching the search criteria. The search results can then be used for other actions.

[SOH] c2Timeout not working as expected


Originally created by @glattercj on Fri, 12 Feb 2021 22:21:46 GMT


When adding the soh app to a scenario config, if a host doesn't have miniccc running (either not injected properly or didn't start properly), the c2 timeout isn't being respected. The experiment stalls and repeats this on a loop:

  [2021-02-12T14:43:50-07:00] waiting for initial network configurations to be validated...
  [2021-02-12T14:43:55-07:00] waiting for initial network configurations to be validated...
  [2021-02-12T14:44:00-07:00] waiting for initial network configurations to be validated...
  [2021-02-12T14:44:05-07:00] waiting for initial network configurations to be validated...
  [2021-02-12T14:44:10-07:00] waiting for initial network configurations to be validated...
  [2021-02-12T14:44:15-07:00] waiting for initial network configurations to be validated...
  [2021-02-12T14:44:20-07:00] waiting for initial network configurations to be validated...

Note: When the specific node foobar-no-miniccc which does not have miniccc installed/running is added to the skipHosts list, the experiment continues to start as normal.

[UI] Ubuntu 18.04.6 Files Tab Date Column Empty

Describe your environment

minimega version: 2.7
Linux distro/version: Ubuntu 18.04.6 LTS/5.4.0-104-generic
Go compiler version:1.17
VM types:kvm

Describe the bug

On Ubuntu 18.04.6 LTS (Bionic Beaver), the Date column on the Files tab for the Running and Stopped experiment views is empty.
missing_date_column_18 04

To Reproduce
Steps to reproduce the behavior:

  1. If an experiment artifact (i.e. PCAP, memory snapshot, etc.) does not exist, create an example artifact. See Phenix documentation (https://phenix.sceptre.dev/vms/) to understand the process to create various experiment artifacts.
  2. From the Running or Stopped experiment list view, left click the Files tab. The Date column will be empty.

Expected behavior
The Date column will display for all Linux distributions.

Better descriptions of phenix sub commands

When you type phenix or phenix experiment you are provided with some nice output showing what commands are available. But if you go further such as phenix experiment schedule or phenix experiment create without any further arguments you are presented with an error message but no clear message regarding what arguments are available and in what order.

image

VM tap list includes comma's in the tap name

When code like the below is ran in an app to get the list of taps associated with a VM all but the last entry in the list has a comma at the end of it.

Code:
taps = next((vm_['tap'] for vm_ in vms_info if vm_['name'] == 'some-vm'), None)

Example Results:
taps: ['mega_tap99,', 'mega_tap100'] or
taps: ['mega_tap92,', 'mega_tap93,', 'mega_tap94']

[UI] Show VM disk referenced in topology

Describe your feature
In the stopped experiment view, the dropdown disk listbox does not show the VM disk referenced in the topology. This can give the impression that a disk is not assigned to the VM.

Feature Details
Stage of Experiment when feature is active: (Creation, Start, Post Start, Running, Stop, Delete)
stage: Stop

Expected behavior
The disk dropdown listbox will show the VM disk referenced in the topology.

Current state
Disk dropdown listbox does not show the disk referenced in the topology
empty_disk

Desired state
Disk dropdown listbox shows the disk referenced in the topology
desired_disk_state

Letter case mismatch with phenix config create/delete

When creating a scenario config (e.g., phenix config create /path/to/scenario.yml), the command line output capitalizes the word "Scenario". If you look at the config list (phenix config list), the word "Scenario" is also capitalized. However, if you then try to delete the scenario with phenix config delete Scenario/test with capitalized "Scenario", there is an error. The "delete" command expects the word "scenario" to be all lowercase. I think this command should either be case insensitive or that the cases should be consistent between the "create" and "delete" commands.

The same error can be seen with topology configs.

Please see attached image for example (identifying information redacted).
phenix_error

Incorporate VMs created outside phenix after startup


Originally created by @jerry-cruz on Fri, 26 Feb 2021 01:07:09 GMT


  1. Create and start an experiment with phenix
  2. Create and launch a new VM using minimega within the experiment (from 1.)

The new VM will not be accessible from the phenix gui, but will be from the minimega ui (both cli and gui). It would be nice if this new VM could function in phenix just as all the other VMs initially deployed.

Use /etc/phenix/store.bdb by default when root, even if root was obtained via sudo


Originally created by @activeshadow on Wed, 20 Jan 2021 18:06:02 GMT


Right now, phenix checks to see if the SUDO_USER env variable is set, and if so it uses the store local to that user. However, SUDO_USER is set even when a user is currently root via sudo su.

The hack way to get around this is to run su - after running sudo su, which unsets the SUDO_USER env variable.

In the code, we should also check the SUDO_COMMAND env variable and only use the store local to the SUDO_USER if the command is for the phenix executable. When someone sudo's to root, the SUDO_COMMAND will be set to something like /bin/su.

[phenix image] Allow building image directly from vmdb config file


Originally created by @glattercj on Wed, 23 Dec 2020 17:19:43 GMT


Add option to pass phenix image build an existing vmdb config file to build from, rather than having to first be in the image datastore. Alternatively, allow phenix image create the same option so an existing vmdb config can be added to the datastore and then built normally.

Add tap info to vm info command


Originally created by @glattercj on Mon, 26 Oct 2020 23:48:41 GMT


Currently there is no way to view tap info (e.g. mega_tap101,megatap102 etc.) via phenix. This info should be optionally available from the phenix vm info <exp name> output.

Additionally, if this info (and basically all runtime info from minimega -e vm info ... was available in the experiment json, that would be very helpful to user apps so they wouldn't have to issue minimega commands themselves.

Delete phenix VM injection snapshots when an experiment is stopped


Originally created by @activeshadow on Thu, 18 Feb 2021 17:03:55 GMT


Right now, we only delete experiment VM injection snapshots right before an experiment is started and when an experiment is deleted. We don't currently delete them when an experiment is stopped just in case we need to pull an injection out, confirm an injection was added, etc. (essentially for debugging purposes).

I propose we change to deleting the injection snapshots by default when an experiment is stopped and add a flag to the experiment stop command to keep the injection snapshots around if necessary.

[enhancement] Start/Stop Packet Captures By Subnet

Describe your feature
It would be convenient to be able to start/stop packet captures by specifying a subnet. The subnet could be specified using the search bar.

Feature Details
Stage of Experiment when feature is active: (Creation, Start, Post Start, Running, Stop, Delete)
stage: Running

Where should feature be visible (current phenix tab and general location or propose a new tab, or not visible)
Buttons could be added to the multiAction toolbar. Alternatively, buttons could be added adjacent to the IPv4 column header to avoid adding additional buttons to the multiAction toolbar.

Expected behavior
When a valid ipv4 subnet is entered into the search bar, a button can be pushed to start packet captures for all VMs that have an interface belonging to the subnet displayed in the search bar. Likewise, when a valid ipv4 subnet is entered and there are current packet captures for the subnet, a button will exist to stop all packet captures for the ipv4 subnet.

Display file inject errors as warnings instead of killing the experiment


Originally created by @c-abate on Tue, 05 Jan 2021 19:10:35 GMT


There are a couple issues here that I noticed when starting up an experiment from the Phenix UI.

  1. The progress bar jumped from 0 - 49% with nothing in between, then a red banner showed saying it failed with a 400 error. The progress bar stayed at 49% and didn't update to show the experiment as stopped. The status only changed to stopped when I refreshed the page.

percent_complete1

  1. The failure is because there was an error when trying to inject a file. This is a known issue, some of the VM's in this experiment do not work with injections. Previously in v5 it would just report the error and move on. Can we go back to that or is there something else that needs to be done?

percent_complete2

Don't require a recompile to enable/disable UI authentication.


Originally created by @activeshadow on Mon, 05 Oct 2020 17:42:48 GMT


Right now, to enable/disable UI authentication, you must do two things:

  1. at compile-time, you must set the VUE_APP_AUTH environment variable to enabled or disabled (the default) when compiling the client-side UI code.
  2. at runtime, you must set the --jwt-signing-key option for phenix ui to a blank string (the default) to disable server-side authentication or to a valid string to enable server-side authentication.

It would be nice to just have to set --jwt-signing-key at runtime and have the client-side UI code adjust accordingly without having to be recompiled.

TLS option for phenix web


Originally created by @aherna on Wed, 27 Jan 2021 00:50:06 GMT


Describe your feature
Have the option to use https using self signed or verified certificates. Should be able to include certificates that have a password protected store

Feature Details
Phenix setup and launch

Expected behavior
Be able to use the ssl certificate to encrypt phenix web traffic

[UI] Killed VMs return on page updates


Originally created by @eric-c-wood on Thu, 25 Feb 2021 20:43:19 GMT


Describe your environment

minimega version: 2.7
Linux distro/version: Ubuntu 20.04.1 LTS/5.8.0-38-generic
Go compiler version:1.14.2
VM types:kvm

Describe the bug

If a VM is killed, the VM is removed from the running experiment view. When the running experiment view is updated (i.e. refresh, sorting, page changes, etc..), the killed VM returns to the running experiment view.

To Reproduce
Steps to reproduce the behavior:

  1. From the running experiment view, open the VM info dialog by clicking on the virtual machine name. Find the kill VM button and kill the VM.
  2. The VM will disappear from the VM list
  3. Update the page by sorting the VM Name column and the killed VM will return to the VM list.

Expected behavior
As the killed VM is no longer part of the experiment, there is currently no UI mechanism to relaunch the killed VM. Consequently, the killed VM should not return to the running experiment view.

[UI] Ubuntu 20.04 crashes during snapshot false launch


Originally created by @eric-c-wood on Thu, 25 Feb 2021 15:29:00 GMT


Describe your environment

minimega version: 2.7
Linux distro/version: Ubuntu 20.04.1 LTS/5.8.0-38-generic
Go compiler version:1.14.2
VM types:kvm
Qemu Version: 4.2.1

Describe the bug

After setting a VM's snapshot flag to false, Phenix will crash when starting the experiment. The qemu instances all get created and the VMs actually start but the running experiment page will fail to load.

To Reproduce
Steps to reproduce the behavior:

  1. Set at least one VM's snapshot flag to false
  2. Start an experiment via the Web UI

Notes
I understand that this issue is almost identical to this closed issue. https://github.com/activeshadow/phenix/issues/20 I was not sure if it was better to create a new issue or simply comment on the old closed issue. The operating system is slightly different from the old issue. If there is a preferred method for future issues, that would be good to know.

From what I can tell, here is why Phenix is crashing.

When the minimega disk info <disk path> command is issued, minimega runs qemu-img info <disk path>. With the way that qemu-img info is being ran, qemu-img returns the following error

Failed to get shared "write" lock

Here is a brief description of the issue https://bugs.launchpad.net/qemu/+bug/1721788

When qemu-img info returns an error, minimega's disk info command returns an error which causes this line to crash https://github.com/activeshadow/phenix/blob/main/src/go/internal/mm/minimega.go#L175

[enhancement] Action on multiple vms


Originally created by @zach-r-long on Thu, 29 Oct 2020 16:47:54 GMT


Describe your feature
Allow a user to perform an action on multiple vms

Feature Details
Stage of Experiment when feature is active: (Creation, Start, Post Start, Running, Stop, Delete)
stage: 'Running'
Where should feature be visible (current phenix tab and general location or propose a new tab, or not visible)
view: 'Experiment Info Tab'

Put checkboxes next to each VM for selection
Display a set of control buttons under VM search box to perform actions:
HDD Snapshot, Memory Dump, Screenshot, Record Screen, Stop Recording

Expected behavior
Allow user to select multiple vms then perform one of the defined actions above to all vms.

Add option for using command and control instead of disk injects


Originally created by @activeshadow on Thu, 21 Jan 2021 22:46:07 GMT


Disk injects can be slow, and with large experiments can fail on partition not found errors randomly. An option to use minimega command and control to add config files to VMs and start/restart services as necessary would help alleviate this.

One approach would be to have a flag on a node config to use command and control, and update the AddInject function to schedule c2 accordingly instead of injecting files. However, this alone won't address the issue of needing to restart services after a config has been updated (e.g. networking).

It's likely that apps will have to handle both cases separately.

An additional image subcommand should be added to add miniccc and boot configs to an existing base image, similar to what the cc-dropper app already does.

Replace interface and startup injection scripts with miniccc


Originally created by @glattercj on Mon, 08 Mar 2021 18:00:41 GMT


Rather than rely on inconsistent Windows startup folders or phenix-startup services for Linux, move towards using miniccc for all startup tasks including setting IPs. The only prerequisite for any image would be: miniccc must be running at boot. For Linux, this is already accomplished using phenix image miniccc-inject, and for Windows would require a pre-bake of virtio drivers and a scheduled task.

minimega error handling bug


Originally created by @GhostofGoes on Tue, 16 Feb 2021 19:47:24 GMT


minimega errors are handled by phenix as fatal errors, which causes experiments to fail to start. The expected behavior is that phenix treats them as warnings and continues starting the experiment regardless.

Example:

root@host:~# phenix experiment start foo
[✓] 'serial' default app (pre-start)
[✓] 'startup' default app (pre-start)
[✓] 'vrouter' default app (pre-start)
[✓] 'ntp' default app (pre-start)
[✓] 'soh' user app (pre-start)
phenix 2021/02/11 16:54:11 [e3ee13a9-8210-4244-b1df-1b0fec818dcb] reading minimega script: reading mmcli script: already in namespace: foo
Error: Unable to start the foo experiment (search error logs for e3ee13a9-8210-4244-b1df-1b0fec818dcb)

[scorch] Use a netns for taps when created as part of the break component

Using a netns for taps will prevent IP collisions across experiments. We can drop the break component terminal directly into the netns using something like the following.

ip netns exec ${NS_NAME} /bin/bash --rcfile <(echo "PS1=\"${NS_NAME}> \"")

A concern is when external network access is needed (e.g., when the break component's tap configuration includes internetAccess). This could still lead to IP collisions across experiments if multiple experiment scorch configs need external network access. One way to remedy this would be to still use a netns, create a veth pair that connects the netns with the main network stack, and use small (/30) IP subnets for the veth pair that phenix tracks and manages. This will require IP masquerading in both the main network stack and the netns, as well as IP forwarding, but will avoid IP collisions across experiment networks.

There's likely other approaches that could be used as well.

[phenix image] Update command not deleting old script from config


Originally created by @glattercj on Fri, 29 Jan 2021 18:38:28 GMT


Each time update is called, it just appends the same script to the end of "script_order". The result is that the script is repeated in the final vmdb file multiple times.

1) phenix cfg edit image/foobar

...
script_order:
    - POSTBUILD_APT_CLEANUP
    - POSTBUILD_NO_ROOT_PASSWD
    - POSTBUILD_PHENIX_HOSTNAME
    - /phenix/vmdb2/scripts/baz
...

2) phenix image update foobar

3) phenix cfg edit image/foobar

...
script_order:
    - POSTBUILD_APT_CLEANUP
    - POSTBUILD_NO_ROOT_PASSWD
    - POSTBUILD_PHENIX_HOSTNAME
    - /phenix/vmdb2/scripts/baz
    - /phenix/vmdb2/scripts/baz
...

Create experiment from scratch from the UI


Originally created by @c-abate on Tue, 05 Jan 2021 18:36:34 GMT


Right now to create an experiment from a new topology and scenario it looks like you have to run a command from the terminal first to load the topologies and scenarios into the data store. It would be really beneficial if it was possible to load these from the phenix UI or have phenix do it automatically if they exist in a certain directory on the server. Reason being that I've noticed on a couple projects that usability is important to adoption and not everyone is comfortable using the terminal to get things done. The more features we can built into the phenix UI so that we don't need to use the terminal would be beneficial.

[UI] Search/Sort Experiment Files

Describe your feature
It would be convenient to be able to search/sort the list of generated experiment files (i.e. packet captures, VM snapshots, memory snapshots, etc..) shown on the Files tab of the running and stopped experiment views.

Feature Details
Stage of Experiment when feature is active: (Creation, Start, Post Start, Running, Stop, Delete)
stage: Running and Stopped

Where should feature be visible (current phenix tab and general location or propose a new tab, or not visible)
The existing Files tab.

Expected behavior
Experiment files can be searched/sorted on the existing Files tab for the running and stopped experiment views. At a minimum, it would be nice to show the file modification date and size. Most of the fields should be searchable with the exception of the download link.

[UI] Cancelling dropdown listbox assignment accepts value

Describe your environment

minimega version: 2.7
Linux distro/version: Ubuntu 20.04.1 LTS/5.8.0-38-generic
Go compiler version:1.14.2
VM types:kvm
Qemu Version: 4.2.1

Describe the bug

On the stopped experiment view, using a dropdown listbox to change the values for host, cpus, memory, or disk will result in a confirmation dialog box with a cancel and assignment button. When the cancel button is pressed, the value selected is stored as the currently selected value.

To Reproduce

  1. Navigate to the stopped experiment view
  2. Change the value for any dropdown listbox
  3. When the confirmation dialog is presented, click the cancel button.
  4. The value selected will be incorrectly stored as the selected value

Expected behavior
When the cancel button on the confirmation dialog is pressed, the selected value does not change.

VM button options missing

Selecting one or more VMs in the VM info tab using the checkboxes does not show any button options. No buttons options are shown in a single VM's info by clicking on it's name either.

Screen Shot 2021-09-08 at 5 09 26 PM

Screen Shot 2021-09-08 at 5 09 34 PM

Add new core user app for creating and managing taps and external network access

This would basically be taking the tap creation code used within scorch and refactoring it such that it could act as a normal phenix app as well. There are times when an experiment needs external network access all the time, not just during a scorch run.

Issue #102 should be addressed prior to at the same time this feature is added to help avoid IP collisions across experiments.

This needs to be a core user app since it will need access to the status of all running experiments in order to decide which IP subnet to use in order to avoid collisions.

Errors and logging


Originally created by @glattercj on Thu, 03 Dec 2020 15:48:58 GMT


There are 2 'phenix' log files that I'm aware of (by default):

  • /var/log/phenix/error.log
  • /var/log/phenix/phenix-apps.log

With phenix ui running inside docker, neither of them are showing this error that I can only see by showing the docker logs:

ERROR handlers.go:176: creating experiment test2 - applying apps to experiment: applying experiment app FOO for action configure: running user app: user app FOO command phenix-app-FOO failed: exit status 1
...
phenix      | AttributeError: 'NoneType' object has no attribute 'get'
phenix      | [✗] 'FOO' experiment app (configure)

If it's not possible to get stderr/stdout from phenix ui running inside a docker container, there should at least be documentation that describes what IS and what ISN'T inside the various log files and where to go to find possible messages (e.g. docker logs).

It would be great to be able to see the error from the UI, but the only options for phenix ui are:

--logs.minimega-path
--logs.phenix-path

Since there are multiple 'phenix' log files, which one should we be using?

[SOH] Add hostFiles option


Originally created by @glattercj on Fri, 12 Feb 2021 17:18:33 GMT


Add option to State Of Health app that verifies the presence of a list of files. This would help verify file injections.

WebSocket client continues to query for screenshot after experiment is stopped.


Originally created by @activeshadow on Tue, 01 Sep 2020 16:53:03 GMT


Once an experiment is started and a user navigates to the running experiment page, the WebSocket client starts polling minimega for VM screenshots every so often. However, it continues to do so even after the experiment is stopped.

Ultimately, the WebSocket client needs to be more intelligent about whether or not anyone is actively needing screenshots and/or whether or not the experiment screenshots belong to are still running.

[SOH] List VM names with Vistual Element on Graph

Inside the state of health option of phenix, there is a visual graph that is generated to view the current experiment topology. In phenix version 5, the VM names are listed with each node presented within the topology graph. This is very handy for figuring out what is what, quickly instead of selecting a node. In phenix version 6 only the nodes are shown with no VM names. This is a lot more confusing. It would be awesome to have this feature from version 5 also implemented for version 6.

Attached are two pictures showing what the version 5 and 6 graph currently looks like.

Version 5
image

Version 6
image

[UI] Enhancement Swap Default Checkbox for Buefy Checkbox


Originally created by @eric-c-wood on Fri, 16 Apr 2021 16:52:25 GMT


On the running experiment view, consider swapping the default checkboxes for Buefy checkboxes.

Buefy checkboxes are easier to interact with due to the size. In addition, Buefy checkboxes have a range of visual customization options that would facilitate any future visual/cosmetic changes. Also, using Buefy checkboxes appears to be more consistent with existing code.

Below is an example of the Buefy checkboxes. Left: color = info Right: color = primary

is_info_buefy is_primary_buefy

The left color is closest to the existing color. We could also use any desired custom color.

Cannot sort VM list while an experiment is running

While an experiment is running it is not possible to sort by VM Name or Host. It used show by default sorted by name but that no longer looks to be the case. When you select the VM Name or Host column header nothing happens except the sort arrow changes direction. Similar results if the VMs are paged or everything is on one page.

One exception sorting Host ascending (arrow pointing up) looks to be working.

This is not a problem when the experiment is not running. In this case the VM defaults to be sorted by name and you can successfully change the sort order.

Drop down sorting for disk images


Originally created by @aherna on Wed, 27 Jan 2021 00:47:28 GMT


Describe your feature
A sorted list of disk images in the drop down for vms. Currently the list seems to change all the time

Feature Details
Prestart phase after experiment gets created
Vm specification page in phenix UI

Expected behavior
Alphabetically sorted list of all available disk images

[UI] Send snapshot flag


Originally created by @eric-c-wood on Thu, 25 Feb 2021 20:14:34 GMT


The snapshot flag should be made available to the UI to avoid running functions that depend on the snapshot flag being set to true. When a dependent function is applied to a single VM, buttons can be disabled/hidden. When a dependent function is applied to multiple VMs, VMs can be skipped.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.