You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 2, 2018. It is now read-only.
The documentation is missing a clear How to install and deploy section. The closest thing to that I can find right now is in DEVEL.rst. Which is not technically part of the documentation. It's a file in the project github repo that's linked from the documentation. The DEVEL.rst file (rightly so) does not give clear instructions on how to run commissaire as a managed system service (ex, supervisord/systemd).
Distribution (packages/pip)
The DEVEL docs reference installing via local/remote pip installs. That's not something I can feel good about doing in a cluster of hosts running business workloads. Ideally this product would be available through OS recommended package install programs (dnf, yum, atomic).
Where's the project going in that direction? Are there plans to get all commissaire components fully installable via Fedora/RHEL Channels/EPEL/AtomicWhatever?
In fedora 25 repos I see there are commissaire and commissaire-client packages with version fields indicating the 0.0.1 release. The git tags say that 0.0.1rc3 was committed on Tue Apr 19 12:05:40 2016 -0400, and since then the CHANGELOG.md file says there has been a new v0.0.3 release made.
The commissaire package includes a unitfile, ./commissaire-0.0.1-2.fc25.noarch/usr/lib/systemd/system/commissaire.service and the commisaire command. Where are the other commands and services? In the commissaire-service repo I can find several unit files
As a system operator I want a set of instructions/tutorial/installation scripts for deploying commissaire
on my infrastructure so that I can run components as proper managed system services rather than as
backgrounded tasks the way described in the current [development documentation].
In my mind, Acceptance Criteria on that story would include
Verify that instructions are provided for running the product as a managed system service (ex: via included supervisord process scripts, systemd unit files, etc)
Verify that package instructions are clear - See the notes above about the old package versions and that they don't install all of the systemd files.
Verify the DEVEL file is properly included as part of the readthedocs.io documentation
Additional Info
Some of this I think requires separate tasks. For example: updating packages in repositories. You can't document that a user should just dnf install commissaire if you know the version is out of date and the documentation no longer reflects the reality of that package.
The text was updated successfully, but these errors were encountered:
@tbielawa Commissaire will be distributed as a container going forward. We won't stop anyone from doing the old school methods of installation, but we expect folks who are using Commissaire for reals to use the containers.
There's no clear way to install this product, especially for those of an enterprise deployment mindset. (pip installs and tasks running in the background just won't cut it)
The packages in Fedora are old and don't reflect the current state of the product
The docs link to various places making it unclear which is the canonical installation instruction, and what's not. There are two separate 'documented' ways of running commissaire, both of those are aimed at development setups
The packages in Fedora are old and don't reflect the current state of the product
@ashcrow Do we want to keep the commissaire Fedora package, then, if we expect this to run containerized? To bring it up-to-date, I would need to package commissaire-http and commissaire-service and get them both through a formal review. I'm more inclined to just nuke it. Thoughts?
(commissaire-client still needs to exist for the CLI.)
Regarding enterprise installation, we're still lacking a unique Dockerfile for each micro-service. Currently all we have is an all-in-one Dockerfile, which is fine for experimenting with Commissaire but not very enterprisey.
Docs
The documentation is missing a clear How to install and deploy section. The closest thing to that I can find right now is in DEVEL.rst. Which is not technically part of the documentation. It's a file in the project github repo that's linked from the documentation. The DEVEL.rst file (rightly so) does not give clear instructions on how to run commissaire as a managed system service (ex,
supervisord
/systemd
).Distribution (packages/pip)
The DEVEL docs reference installing via local/remote
pip
installs. That's not something I can feel good about doing in a cluster of hosts running business workloads. Ideally this product would be available through OS recommended package install programs (dnf
,yum
,atomic
).Where's the project going in that direction? Are there plans to get all commissaire components fully installable via Fedora/RHEL Channels/EPEL/AtomicWhatever?
In fedora 25 repos I see there are
commissaire
andcommissaire-client
packages with version fields indicating the0.0.1
release. The git tags say that0.0.1rc3
was committed onTue Apr 19 12:05:40 2016 -0400
, and since then theCHANGELOG.md
file says there has been a newv0.0.3
release made.The
commissaire
package includes a unitfile,./commissaire-0.0.1-2.fc25.noarch/usr/lib/systemd/system/commissaire.service
and thecommisaire
command. Where are the other commands and services? In thecommissaire-service
repo I can find several unit filesI can see vague references to the systemd services in the
Vagrantfile
. But again, even this is only referenced in a development context.Docs: enterprisey installation instructions
In the form of a user story
In my mind, Acceptance Criteria on that story would include
supervisord
process scripts,systemd
unit files, etc)Additional Info
Some of this I think requires separate tasks. For example: updating packages in repositories. You can't document that a user should just
dnf install commissaire
if you know the version is out of date and the documentation no longer reflects the reality of that package.The text was updated successfully, but these errors were encountered: