The ara-server standalone repository is being discontinued.
The clear and logical separation of components was nice but the overhead
in complexity was not worth it.
Change-Id: I9d5e3096db4972405932ae2af46ee63bfeef43b5
Files are now (once again) related to playbooks.
We expect the playbook to be created first and then it's files are
created and associated to it.
- the /api/v1/playbook/<id>/files endpoint was removed
- the playbook id is now required when doing a POST on /api/v1/files
- playbook.file referenced a file object and no longer exists.
- playbook.file was replaced by "path" which is the path for the playbook
file.
- playbook.files still exists but, from an API standpoint, this means
that to find the files associated to a playbook, we can now do
something like:
"/api/v1/files?playbook=%s" % playbook.id
To find the playbook file itself, we can do something like:
"/api/v1/files?playbook=%s&path=%s" % (playbook.id, playbook.path)
Change-Id: Id51129757e1626313caee4005b081027e5694aba
This adds the API support for implementing records in ARA that are meant
to be used by the ara_record and ara_read modules.
Change-Id: I162de3859ec05fb51d190753fe073c48ed6f8823
Changes include:
* Custom admin app config instead of monkey patching attributes.
* DRF Routers & Viewsets instead of manual view configuration.
* nested viewsets from drf-extensions (for now) to scope files to playbooks.
* Removed media serving since runserver does this alreay in dev;
deployment will need another option anyways.
Change-Id: I409bd3f7faa5f133fcb204613baebf2512d34c1a
- Reset database migrations back to initial (database schema is not
stable or supported yet, let's not burden ourselves with migrations
needlessly)
- Move host stats to a Stats model
- Tie the hosts back to the playbook instead of the play
While hosts are in fact "children" of plays, Ansible doesn't provide
stats per-play. From ARA's perspective, it's simpler to keep hosts at
the same level as the stats.
Depends-On: https://review.openstack.org/600058
Change-Id: I127efd79a5077488ffa084d2784d5a3c6f2da2da
A report is a generic container meant to group or correlate different
playbooks.
It could contain a single playbook run or a group of playbook runs.
It can also be used to represent phases or dynamic tagging of playbook
runs.
For example, you could have a report named "failures" and make it so
failed playbooks are added to this report, for example.
The main purpose of this is to make reports generic and dynamic from
an API standpoint so we can build on top of this later.
Change-Id: I398f0337987abe31fa1e886f66ec9c3e644a32d6
This is a structure that will allow us to install everything under
"ara" as separate packages but inside the same module.
For example, installing ara-server will provide ara.server and
ara.api.
Installing ara-clients will provide ara.clients, ara-plugins will
supply ara.plugins, etc.
Change-Id: I27ee431c4e5d946f558befc12937ba2f3c0d020b
David Moreau Simard