tl;dr I’d like to use a slot in the cross-project track to discuss the best way of managing cross-project, multi-cycle initiatives, using the forthcoming Cloud Service Federation (Broker) project to make it concrete rather than theoretical. Desired outcome: recommendations to Product group, verticals, TC on the right governance for such initiatives.
[Doug asked me to expand on my earlier proposal, and get your feedback.] There’s a lot of interest in the broad topic of Federation of OpenStack services, by which I mean the delivery and consumption of cloud services using multiple independently operated clouds. There are various use cases, including reseller, broker, and cloud-bursting, each with specific requirements. For many people, “federation” is interpreted as an identity management problem; here we’re taking a broader view. During Kilo, the Keystone team implemented a number of features (hierarchical multitenancy, Keystone-to-Keystone, and others) which are key enabling technologies for broader service federation. We (I work for Cisco Intercloud Services) are planning to launch a Stackforge project to develop a complete solution for one of the use cases: a Broker system which supports the aggregation of virtual regions for resale or other consumption patterns. Why would this be of interest in the cross-project session, and what would we want to get out of such a discussion? Well, the Broker project will depend on new work in various projects. At a minimum, we anticipate that it will involve Horizon (DB-backed configuration, as in Keystone), Nova (quotas), Glance (resource ownership and visibility), and Ceilometer (domain-aggregated queries). There will be more. In some cases, we expect the work to extend over a couple of cycles. If this were a unique case, we’d probably resort to the traditional approach of filing multiple blueprints and working one-on-one with PTLs. However, there is reason to believe that this kind of situation is going to become more common. We have several working groups (Win The Enterprise, NFV, etc.) that are developing systems-level requirements for OpenStack, and whose success will depend on multiple-project, multiple-cycle coordination. The Product Management group which was formed after Paris is proposing to play a role in this area - is that the right approach? Meanwhile we are moving towards a new tag-based project governance framework (not to mention a new branding regime). So my purpose in bringing the Cloud Service Federation project to the cross-project track is to discuss how we want to handle this kind of systems-level initiative (“epic”, if you like). How should we manage the dependencies and priorities? Are the existing methods adequate, or do we need a more formal approach? This kind of discussion is often frustrating in the abstract, as we saw at several sessions in Paris. Thanks to the Keystone team’s work in Kilo, we’re about to launch a very specific, concrete project, and I think this will make the discussion of alternative governance more productive. Geoff __________________________________________________________________________ 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
