project proposal

This commit is contained in:
MasterDefault committed 2026-10-06 19:12:47 -04:00
1 parent c9d06e0b5a
commit 13bce6144c
5 files changed
+132 -17

No files matched your search

+21
View File
@@ -100,3 +100,24 @@ Codex copied additions into the student's supplied course repository location.\\
compiler work was not present in the inspected repository. Full compilation, compiler work was not present in the inspected repository. Full compilation,
combined report review, repository publication, and Canvas submission are not combined report review, repository publication, and Canvas submission are not
claimed by this record. claimed by this record.
\subsection{Record 6 --- Inviscid Project Proposal}
\textbf{Date:} October 6, 2026.\\
\textbf{Tool:} OpenAI Codex.\\
\textbf{Task:} Brainstorm Inviscid, refine the metrics-tool comparison and
research question, and write the approved proposal into the course repository.\\
\textbf{Inputs:} The assignment outline, instructor clarification, Victor's
project preferences and corrections, current repository sources, and official
Prometheus and VictoriaMetrics documentation.\\
\textbf{Output used:} Project description, sample task, tentative tool choices,
research question, planned comparison, independent SWOT assessments, and
supporting document updates.\\
\textbf{Human decisions and corrections:} Victor approved the monitoring-service
concept, selected VictoriaMetrics instead of InfluxDB, approved the research
question, and requested independent SWOT assessments and candidate tools
explicitly marked undecided.\\
\textbf{Review boundary:} The monitoring prototype, tool comparison, and
pipeline remain proposed work. No performance results or completed monitoring
features are claimed. The combined report still requires final author review
and compilation before submission.
+106 -14
View File
@@ -1,19 +1,111 @@
\chapter{Project Proposal} \chapter{Project Proposal}
\ChapterLabel{ProjectProposal} \ChapterLabel{ProjectProposal}
\index{GitHub Actions}\index{Jenkins} \index{Inviscid}\index{Prometheus}\index{VictoriaMetrics}\index{observability}
\section{Proposed Tool: GitHub Actions} \section{Inviscid: Simple Monitoring for Small Web Services}
We propose researching GitHub Actions and comparing it with Jenkins, which Inviscid is a proposed customer-facing startup that helps small businesses
will be introduced in class. GitHub Actions interests us because our group monitor the health and performance of their web applications. Customers would
already uses GitHub to maintain source code and documentation. We want to use a dashboard to view availability, response times, request volume, and
understand how repository workflows can automate the build, testing, and error rates. The service would pair these measurements with plain-language
deployment of our Dockerized website to AWS. status summaries, such as ``Your website is responding slowly,'' to help
customers recognize problems without requiring extensive monitoring expertise.
Our comparison will consider setup effort, workflow configuration, and The semester prototype will focus on one demonstration customer application,
visibility into build and deployment results. A future demonstration could building on our existing Node.js website. The broader startup concept is a
provide a manually triggered workflow that builds and deploys the application. future direction; customer account management and support for multiple
For this proposal, no installation or implementation of the comparison tool customers are outside the initial prototype. Our current proof of concept is
is claimed. The current proof of concept is the manually deployed EC2 website. the Dockerized Color Buttons website deployed on AWS, documented in
\ChapterRef{CloudDockerDeployment}. Monitoring and deployment automation are
proposed work rather than completed features.
% Draft selection based on the earlier discussion: both authors should confirm \subsection{Sample Customer Task}
% GitHub Actions versus Jenkins before submitting this chapter. A customer opens the Inviscid dashboard to check their website's health.
During a controlled demonstration, we will generate normal traffic and then
introduce slow responses or failed requests in the sample application. The
dashboard should display the resulting changes in response times and error
rates, accompanied by a short status summary explaining the problem.
\section{Proposed Development and Operations Tools}
GitHub will provide source control and collaboration, and AWS will provide
the deployment environment. Table~\ref{Table:InviscidTools} lists the planned
stack. Entries marked undecided are candidates, not commitments; the team
may revise them as implementation requirements become clearer.
\begin{tabularx}{\linewidth}{L{3.2cm}Y}
\caption{Tentative Inviscid Tool Selection\label{Table:InviscidTools}}\\
\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
\endfirsthead
\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
\endhead \bottomrule \endlastfoot
Source control & GitHub; selected.\\
Application & Node.js and Express; proposed, building on the existing website.\\
Container packaging & Docker; selected.\\
Deployment & AWS EC2; selected for the prototype.\\
Metrics backend & Prometheus and single-node VictoriaMetrics; selected for comparison, final backend undecided.\\
Dashboard & Grafana or a simple custom dashboard; undecided.\\
Automated testing & Node.js's built-in test runner and a traffic-generation script; undecided.\\
Deployment automation & GitHub Actions for a manually triggered build, test, and deployment workflow; undecided.\\
Customer/settings database & Amazon DynamoDB, if persistent customer configuration is needed; undecided. Metrics will be stored in the selected metrics backend.\\
Security checks & GitHub Dependabot and automated dependency checks; undecided.\\
\end{tabularx}
Our longer-term goal is a deployment pipeline that can be initiated with one
button press. The proposal does not claim that this pipeline is implemented.
\section{Research Question and Planned Comparison}
\begin{quote}
How do Prometheus and VictoriaMetrics compare as metrics backends for
Inviscid's prototype in terms of configuration effort, dashboard integration,
query response time, and CPU, memory, and storage usage?
\end{quote}
We selected these tools because both can collect and query application metrics,
and VictoriaMetrics can scrape Prometheus-compatible endpoints. This allows
us to reuse the instrumented application while investigating different
backend implementations. Prometheus includes metric scraping, PromQL queries,
and alert-rule evaluation. VictoriaMetrics provides metric collection and
storage with MetricsQL queries; alert-rule evaluation uses a separate component
such as \texttt{vmalert}. Supported configuration options and query behavior
will be checked rather than assumed identical.
We plan to compare Prometheus with single-node VictoriaMetrics using the same
application, metrics, traffic workload, collection interval, retention period,
and equivalent AWS resources. Configuration effort will be documented through
setup steps and difficulties; dashboard integration through the work required
to display equivalent measurements. Repeated equivalent queries and controlled
traffic will support measurements of query response time and CPU, memory,
and storage usage. Results will apply to the tested prototype and workload;
we will not assume that either tool is faster or more resource-efficient.
\section{Preliminary SWOT Analysis}
Table~\ref{Table:InviscidSWOT} evaluates each tool independently in the context
of Inviscid. Strengths and weaknesses describe tool characteristics;
opportunities and threats describe possible circumstances affecting its use.
These are preliminary assessments, not measured experimental results.
\begingroup
\small
\begin{tabularx}{\linewidth}{L{2.0cm}YY}
\caption{Preliminary SWOT for Inviscid's Metrics Backends\label{Table:InviscidSWOT}}\\
\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
\endfirsthead
\multicolumn{3}{l}{\small\itshape Preliminary SWOT (continued)}\\
\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
\endhead \bottomrule \endlastfoot
Strengths & Established open-source ecosystem; built-in metric collection and alert-rule evaluation; expressive PromQL query language. & Simple single-node deployment; built-in metric collection and storage; flexible MetricsQL query language and multiple supported ingestion formats.\\
Weaknesses & Local storage is neither clustered nor replicated; operating at larger scales requires additional architecture. & Alert-rule evaluation requires a separate component; the single-node deployment depends on one server for availability.\\
Opportunities & Inviscid could extend monitoring to containers and infrastructure through its existing exporter ecosystem. & Inviscid could accept metrics from different customer environments through its supported ingestion formats.\\
Threats & Rapid growth in customer metrics could exceed available resources and increase operating costs. & Customers requiring uninterrupted monitoring could necessitate a cluster deployment, increasing infrastructure and maintenance costs.\\
\end{tabularx}
\endgroup
\section{Technical Sources}
The technical characteristics above are based on the following official
documentation, consulted October 6, 2026. Opportunities and threats are the
team's project-specific assessments. Specific tool versions will be recorded
when the comparison is implemented.
\begin{itemize}
\item \href{https://prometheus.io/docs/introduction/overview/}{Prometheus overview}: collection, queries, exporters, and alerting components.
\item \href{https://prometheus.io/docs/prometheus/latest/storage/}{Prometheus storage}: local storage limitations and remote storage interfaces.
\item \href{https://docs.victoriametrics.com/victoriametrics/}{VictoriaMetrics documentation}: single-node deployment, scraping, ingestion, MetricsQL, and supporting components.
\end{itemize}
+2 -2
View File
@@ -40,14 +40,14 @@
% Replace these values for each assignment. % Replace these values for each assignment.
\newcommand{\AssignmentTitle}{Cloud Docker Deployment, LaTeX Docker, and Project Proposal} \newcommand{\AssignmentTitle}{Cloud Docker Deployment, LaTeX Docker, and Project Proposal}
\newcommand{\AssignmentNumber}{3} \newcommand{\AssignmentNumber}{3}
\newcommand{\DocumentVersion}{3.1} \newcommand{\DocumentVersion}{3.2}
\newcommand{\DocumentStatus}{Group Report Draft} \newcommand{\DocumentStatus}{Group Report Draft}
\newcommand{\CourseNumber}{SSW 590} \newcommand{\CourseNumber}{SSW 590}
\newcommand{\CourseName}{DevOps} \newcommand{\CourseName}{DevOps}
\newcommand{\Author}{Payton Bates and Victor Del Rio Foces} \newcommand{\Author}{Payton Bates and Victor Del Rio Foces}
\newcommand{\Instructor}{Darian Muresan, Ph.D.} \newcommand{\Instructor}{Darian Muresan, Ph.D.}
\newcommand{\Organization}{Stevens Institute of Technology} \newcommand{\Organization}{Stevens Institute of Technology}
\newcommand{\DocumentDate}{October 5, 2026} \newcommand{\DocumentDate}{October 6, 2026}
\newcommand{\DueDate}{October 6, 2026 by 11:59pm} \newcommand{\DueDate}{October 6, 2026 by 11:59pm}
\newcommand{\VERSION}{Version \DocumentVersion} \newcommand{\VERSION}{Version \DocumentVersion}
+2 -1
View File
@@ -7,4 +7,5 @@ distinguishes machines in service from those still planned.
Assignment 3 adds the class-based Color Buttons application deployed in Docker Assignment 3 adds the class-based Color Buttons application deployed in Docker
on Amazon EC2, with public browser and terminal verification evidence; on Amazon EC2, with public browser and terminal verification evidence;
a Docker container that compiles \LaTeX\ documents as Overleaf does; a Docker container that compiles \LaTeX\ documents as Overleaf does;
and a proposal to compare GitHub Actions with Jenkins. and the Inviscid monitoring-service proposal, including a planned comparison
of Prometheus and VictoriaMetrics.
+1
View File
@@ -11,6 +11,7 @@ link each entry to the changed chapter, table, figure, or controlled artifact.
\multicolumn{4}{l}{\small\itshape Document Update History (continued)}\\ \multicolumn{4}{l}{\small\itshape Document Update History (continued)}\\
\toprule \textbf{Date / Version} & \textbf{Author Initials} & \textbf{Change} & \textbf{Changed At}\\ \midrule \toprule \textbf{Date / Version} & \textbf{Author Initials} & \textbf{Change} & \textbf{Changed At}\\ \midrule
\endhead \bottomrule \endlastfoot \endhead \bottomrule \endlastfoot
October 6, 2026 / 3.2 & VDRF & Replaced the preliminary tool proposal with Inviscid, its sample customer task, tentative stack, research question, and independent SWOT assessments of Prometheus and VictoriaMetrics. Updated the abstract and AI log. & \ChapterRef{ProjectProposal}, \ChapterRef{AIPromptLog}\\
October 5, 2026 / 3.1 & PCB & Added the LaTeX Docker chapter for compiling a sample document with its sources, build and run commands, and test evidence. Updated the document title, keywords, glossary, abstract, introduction, and hosts. & \ChapterRef{LatexDocker}, \ChapterRef{Hosts}, \ChapterRef{Introduction}, \ChapterRef{CloudDockerDeployment}\\ October 5, 2026 / 3.1 & PCB & Added the LaTeX Docker chapter for compiling a sample document with its sources, build and run commands, and test evidence. Updated the document title, keywords, glossary, abstract, introduction, and hosts. & \ChapterRef{LatexDocker}, \ChapterRef{Hosts}, \ChapterRef{Introduction}, \ChapterRef{CloudDockerDeployment}\\
October 5, 2026 / 3.0 & VDRF & Added AWS Docker deployment, class-based website sources, execution evidence, and a draft tool-comparison proposal. Updated Assignment 3 metadata and AI log. & \ChapterRef{CloudDockerDeployment}, \ChapterRef{ProjectProposal}, \ChapterRef{AIPromptLog}\\ October 5, 2026 / 3.0 & VDRF & Added AWS Docker deployment, class-based website sources, execution evidence, and a draft tool-comparison proposal. Updated Assignment 3 metadata and AI log. & \ChapterRef{CloudDockerDeployment}, \ChapterRef{ProjectProposal}, \ChapterRef{AIPromptLog}\\
September 27, 2026 / 2.1 & VDRF & Added Victor's Q1--Q40 execution screenshots and result interpretation; distinguished the two environments and command variants. & \ChapterRef{LinuxCommands}, \ChapterRef{AIPromptLog}\\ September 27, 2026 / 2.1 & VDRF & Added Victor's Q1--Q40 execution screenshots and result interpretation; distinguished the two environments and command variants. & \ChapterRef{LinuxCommands}, \ChapterRef{AIPromptLog}\\