Open Stack

The Architecture Working Group was lucky enough to have a room allocated
to us for all day Tuesday of the Pike PTG. We made good use of it
to do what we are here to do: Facilitate the development of a shared
architecture amongst OpenStack project teams.

We had an etherpad[1] that is a bit of a stream of consciousness, so
I'll attempt to distill it into topics:

Base Services
-------------

The base-services document recently landed in the governance repo[2],
defining the minimum things that any project can expect to have in a
deployment. The next step is to develop a process for evaluating the set
of base services. The topic of reducing "an oslo.db database" to just
"mysql" was mentioned, but that is happening more at the TC level and
was not something any of us in the arch-wg came prepared to discussion.


DLM
---

We did have a lively update on DLM adoption in OpenStack, and whether or
not it's time to have a base service discussion about DLM's (like
Zookeeper or etcd). There was some confusion as to whether Cinder needs
it. We learned that you can run Cinder without it, but having a DLM behind
Cinder allows you to run cinder-volume active/active/... vs. just
active/passive. Also drivers in Cinder can rely on a properly configured
DLM to protect remote resources, which is cool. This isn't really our
spec, but we want to make sure we help socialize it so that we can come
back and have the conversation about base services and DLMs later. There
was also some push back on that very idea from a few Nova developers who
felt that Nova does not need a DLM, but this isn't about projects who
don't need one, it's about those that were already identified long ago
in the spec that do need one.

Barbican
--------

As part of the work to investigate new potential base services, we had a
lengthy discussion with the Barbican team and members of the security
team about whether projects need key management, and if they do, should
they use Barbican. This was complex, and probably needs a more detailed
write-up. Suffice to say, we do think that the Castellan library which
abstracts key management away from Barbican is a good start at having a
similar experience to "... an oslo.db database." As such, there will be
an effort made to look into renaming Castellan to "oslo.keymanager"
given that it is already in the dependency chain for several projects
and fits exactly into oslo's model of "the way OpenStack uses
keymanagers." There was some discussion about potentially using
non-Barbican key management solutions, such as just writing to
HashiCorp's Vault directly, or also looking at something like the
relatively untested, but very interesting "Tang/Clevis"[3] using the
McCallum-Relyea key exchange algorithm. It was a really interesting
conversation, and I expect more analysis to come out soon hopefully. For
now there aren't many actions to report.

Nova Compute API
----------------

I'll be honest, I don't really know what happened in that room. I was
hoping to get feedback from all of the projects, but it mostly turned
into Nova explaining to me all the abstractions they've added that make
nova-compute less of a layer violation than it used to be. I take the
relative silence of other projects as either Stockholm Syndrome, or
evidence that they agree and there's nothing to see here. In all, I
learned a lot and will produce some analysis myself soon based on the
facts we gathered in the etherpad[4] and in my brain.

Hierarchical Quotas
-------------------

This wasn't really our show, but it happened in the Arch-WG space and I
learned a lot. I think Matt Riedemann already covered the prescient
points from this discussion. The etherpad [5] contains the details.

[1] https://etherpad.openstack.org/p/ptg-architecture-workgroup
[2] https://governance.openstack.org/tc/reference/base-services.html
[3] https://github.com/latchset/tang
[4] https://etherpad.openstack.org/p/arch-wg-nova-compute-api-ptg-pike
[5] https://etherpad.openstack.org/p/ptg-hierarchical-quotas