9fefbfe85b
Because of how vague the scope of Adjutant is (for a reason) we need a way to define what actually fits in a sensible way. The new guide lines are part of that, and we're also now adding a section to our docs about the project history to explain why the scope is so vague and how it got there. Plus a section on project features, to help define what it can do. Change-Id: I7d05c1f43570843171a4144ece2228efc3227cce
86 lines
4.8 KiB
ReStructuredText
86 lines
4.8 KiB
ReStructuredText
Project History
|
|
===============
|
|
|
|
Adjutant was started by CatalystCloud to fill our needs around missing
|
|
features in OpenStack. CatalystCloud is public cloud provider based in New
|
|
Zealand with a strong focus on opensource, with a team of operators and
|
|
developers who are all contributors to OpenStack itself.
|
|
|
|
Early prototyping for Adjutant began at the end of of 2015 to fill some of the
|
|
missing pieces we needed as a public cloud provider. It was initially something
|
|
we had started designing as far back as early 2014, with the scope and design
|
|
changing many times until initial prototyping and implementation was started in
|
|
late 2015.
|
|
|
|
Originally it was designed to act as a service to manage customers, their
|
|
users, projects, quotas, and to be able to process signups and initial resource
|
|
creation for new customers. It would act as a layer above OpenStack and most
|
|
non-authentication based identity management from a user perspective would
|
|
happen through it, with the service itself making the appropriate changes to
|
|
the underlying OpenStack services and resources. The reason why it didn't end
|
|
up quite so complex and so big is because OpenStack itself, and many of the
|
|
services (and the future roadmap) had planned solutions to many of the things
|
|
we wanted, and our business requirements changed to storing our customer
|
|
information in an eternal ERP system (Odoo/OpenERP at the time) rather than a
|
|
standalone service.
|
|
|
|
So instead of something so grand, we tried smaller, a service that handles our
|
|
unique public cloud requirements for signup. It should take in signup data from
|
|
some source such as a public API that our website posts to, then validate it,
|
|
give us those validation notes, and lets us decide if we wanted that customer,
|
|
or even have the system itself based on certain criteria approve that customer
|
|
itself. It would then create the user in Keystone, create a project, give them
|
|
access, create a default network, and then also link and store the customer
|
|
data in our ERP and billing systems. This was the initial
|
|
'openstack-registration' project, and the naming of which is present in our git
|
|
history, and where the initial service-type name comes from.
|
|
|
|
As we prototyped this we realised that it was just a workflow system for
|
|
business logic, so we decided to make it flexible, and found other things we
|
|
could use it for:
|
|
|
|
- Allowing non-admin users to invite other users to their project.
|
|
- Let users reset their password by sending an email token to them.
|
|
- Manage and create child-projects in a single domain environment.
|
|
- Request quota increases for their projects.
|
|
|
|
All with the optional step of actually requiring an admin to approve the user
|
|
request if needed. And with a good audit trail as to where the actions came
|
|
from, and who approved them.
|
|
|
|
Eventually it also got a rename, because calling it OpenStack Registration got
|
|
dull and wasn't accurate anymore. The name it got at the time was StackTask,
|
|
and there are still elements of that naming in our systems, and plenty in the
|
|
git history. Eventually we would rename it again because the name still being
|
|
feel right, and was too close to StackTach.
|
|
|
|
Around that time we also added plugin support to try and keep any company
|
|
specific code out of the core codebase, and in the process realised just how
|
|
much further flexibility we'd now added.
|
|
|
|
The service gave us an easy way to build APIs around workflow we wanted our
|
|
customers to be able to trigger around larger normally unsafe admin APIs in
|
|
OpenStack itself. With the ability to have those workflows do changes to our
|
|
ERP system, and other external systems. It gave us the missing glue we needed
|
|
to make our public cloud business requirements and logic actually work.
|
|
|
|
But we were always clear, that if something made better sense as a feature in
|
|
another service, we should implemented in that other service. This was meant to
|
|
be a glue layer, or potentially for mini API features that don't entirely have
|
|
a good place for them, or just a wrapper around an existing OpenStack feature
|
|
that needs organisation specific logic added to it.
|
|
|
|
Throughout all this, the goal was always to keep this project fully opensource,
|
|
to invite external contribution, to do our planning, bug tracking, and
|
|
development where the OpenStack community could see and be transparent about
|
|
our own internal usage of the service and our plans for it. The code had been
|
|
on our company github for a while, but it was time to move it somewhere better.
|
|
|
|
So we renamed again, and then finally moved all the core repos to OpenStack
|
|
infrastructure, as well as the code review, bug, and spec tracking.
|
|
|
|
Adjutant, in it's current form is the culmination of that process, and while
|
|
the core driving force behind Adjutant was our own needs, it always was the
|
|
intention to provide Adjutant for anyone to build and use themselves so that
|
|
their effort isn't wasted threading the same ground.
|