Clint Byrum wrote:
Excerpts from Joshua Harlow's message of 2016-08-13 20:04:13 -0700:
The larger issue here IMHO is that there is now a<between-project> API
around locking that might be better suited targeting an actual lock
management system (say redis or zookeeper or etcd or ...).
The more I look at this, the more I think this is just evidence that
the compute node itself needs to be an API unto itself. Whether it's
Neutron agents, cinder volumes, or what, nova-compute has a bunch of
under-the-covers interactions with things like this. It would make more
sense to put that into its own implementation behind a real public API
than what we have now: processes that just magically expect to be run
together with shared filesystems, lock dirs, network interfaces, etc.
That would also go a long way to being able to treat the other components
more like microservices.
I very much agree, the amount of interactions 'under-the-covers' makes
it really hard to do many things (including understanding what those
interactions even are). For example, how does someone even install
'os-brick' at this point, if it requires as a prerequisite that cinder
and nova-compute be pre-setup with the <same lock dir>? Sucks I guess
for people/operators/anyone using both components, that are already
running those with different lock directories...
IMHO the amount of time done 'hacking in solutions' like a shared lock
directory (or moving both projects to share the same configuration
somehow) would be better spent on an actual locking solution/service and
thinking about microservices and ... but meh, what can u do...
-Josh
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
