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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev