In the spirit of summarizing conversations that have been had, I'd like to point people that are interested at the Devstack FUTURE.rst document - https://github.com/openstack-dev/devstack/blob/master/FUTURE.rst
This is an attempt by the Devstack team recently to write down a "where are we going" document, which helps contributors and reviewers figure where we are headed, and help us along that path. A big piece of this is external Devstack plugins, which lets a project keep their Devsack enable code within their own source tree, and let people easily add their project to a local devstack with a single ``enable_plugin`` line. (And lets you even do gate jobs with pretty minimal additional configuration). I've been working with the ec2api, glusterfs, and opendaylight folks on their initial plugins over the past couple of weeks and the results have been really promising that this is a much better long term evolution for everyone. Once we get a few more examples live and working, I think we'll be ready for a best practices document in the devstack docs tree. == Grenade == Based on the early successes here, I think Grenade is going to need to go a similar path. Part of what made doing Devstack plugins out of tree pretty clear was that extras.d/ already defined a pretty reasonable set of phases, and we had a bunch of projects that were already supported in tree in that model. I'm sure we'll need some additional hook points in the future, but we can roll that out in a backwards compatible way, or at least with a long enough multi cycle deprecation that everyone can catch up. For grenade, we've got 2 call out interfaces we need to care about. 1) the upgrade-* scripts This + the from-/within- parts are all project specific, and you can imagine how that could be moved out of tree if we guarunteed some exported variables (like TOP_DIR) and move things like etc saving and db-sync into common call paths. It's some work, but not really much new invention. 2) resource survivability In grizzly this was done ad-hoc, and we broke it for a while. In juno we rebuilt a tool (javelin2) to try to give us a unified view of the world. That turned out more difficult and more coupled that we expected. I think for Liberty we need to step back on this and define the interface, and let the implementations evolve behind it. So we need something like: resources.sh [create|verify|verify-noapi|delete] old: resources.sh create resources.sh verify downforupgrade: resources.sh verify-noapi new: resources.sh verify done: resources.sh delete in the create phase you build your resources, we call out to verify before we shut down services, after services are down we call verify-noapi, and after they are up again we call verify. We need 2 verify calls because we want to test that things like computes weren't deleted when nova-compute was down. The back end for these might be openstack cli commands, a chunk of python code, ansible, doesn't really matter much. The interface contract should provide us isolation for that. I think all of this is probably a Liberty timeline, because I just can't imagine anyone getting around to it still in this cycle. Which leaves the open question of additional project support in Grenade. I think right now we should not add much more to Grenade during this cycle, because I expect that's more we have to unwind in the next. So for projects not in upgrade testing yet, lets hold off. Will try to have a prototype up for Vancouver discussion and make things a lot more inclusive for projects in Liberty. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ 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