[openstack-dev] [ptl][kolla][release] Deploying the big tent
kevin.carter at RACKSPACE.COM
Tue Mar 29 02:54:19 UTC 2016
On 03/28/2016 08:17 PM, Steven Dake (stdake) wrote:
> On 3/27/16, 2:50 PM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> wrote:
>> On 3/26/2016 11:27 AM, Steven Dake (stdake) wrote:
>>> Hey fellow PTLs and core reviewers of those projects,
>>> Kolla at present deploys the compute kit, and some other services that
>>> folks have added over time including other projects like Ironic, Heat,
>>> Mistral, Murano, Magnum, Manilla, and Swift.
>>> One of my objectives from my PTL candidacy was to deploy the big tent,
>>> and I saw how we were not super successful as I planned in Mitaka at
>>> filling out the big tent.
>>> While the Kolla core team is large, and we can commit to maintaining big
>>> tent projects that are deployed, we are at capacity every milestone of
>>> every cycle implementing new features that the various big tent services
>>> should conform to. The idea of a plugin architecture for Kolla where
>>> projects could provide their own plugins has been floated, but before we
>>> try that, I'd prefer that the various teams in OpenStack with an
>>> interest in having their projects consumed by Operators involve
>>> themselves in containerizing their projects.
>>> Again, once the job is done, the Kolla community will continue to
>>> maintain these projects, and we hope you will stay involved in that
>>> It takes roughly four 4 hour blocks to learn the implementation
>>> architecture of Kolla and probably another 2 4 hour blocks to get a good
>>> understanding of the Kolla deployment workflow. Some projects (like
>>> Neutron for example) might fit outside this norm because containerizing
>>> them and deploying them is very complex. But we have already finished
>>> the job on what we believe are the hard projects.
>>> My ask is that PTLs take responsibility or recruit someone from their
>>> respective community to participate in the implementation of Kolla
>>> deployment for their specific project.
>>> Only with your help can we make the vision of a deployment system that
>>> can deploy the big tent a reality.
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> Having never looked at Kolla, is there an easy way to see what projects
>> are already done? Like, what would Nova need to do here? Or is it a
>> matter of keeping up with new deployment changes / upgrade impacts, like
>> the newish nova API database?
>> If that's the case, couldn't the puppet/ansible/chef projects be making
>> similar requests from the project development teams?
>> Unless we have incentive to be contributing to Kolla, like say we
>> replaced devstack in our CI setup with it, I'm having a hard time seeing
>> everyone jumping in on this.
> The compute kit projects are well covered by the current core reviewer
> team. Hence, we don't really need any help with Nova. This is more aimed
> at the herd of new server projects in Liberty and Mitaka that want
> deployment options which currently lack them. There is no way to deploy
> aodh in an automated fashion (for example) (picked because it was first in
> the project list by alphabetical order;)
Just as a point of correction, there is an automated way to deploy AODH
The AODH project is, and has been, well represented by the
OpenStack-Ansible community for some time. The role and playbooks were
created back in Liberty  on Oct 7 2015 and has been part of our
integrated gate since it's acceptance into the core OpenStack-Ansible
project. Recently the "os_"aodh role has been split out into its own
repository for use as a stand alone role. The OSA role can be found
 - https://github.com/openstack/openstack-ansible-os_aodh
> For example this cycle community folks implemented mistral and manila,
> which were not really top in our priority list. Yet, the work got done
> and now the core team will look after these projects as well.
> As for why puppet/ansible/chef couldn't make the same requests, the answer
> is they could. Why haven't they? I can never speak to the motives or
> actions of others, but perhaps they didn't think to try?
While I also can not speak to the intentions of others I will say I've
never felt the need to burden other communities with deployment code for
a given service because its generally not part of their development
workflow. When I've been working on a service and needed things from the
community developing that service I've reached out to them directly. As
someone working on deployment code its been been great to get additional
developer feedback from folks outside of our community; this is
something everyone in the OpenStack-Ansible community is encouraged to
do for all of the services we support. External interactions with other
communities have been invaluable and greatly improved our project. All
that said, if PTLs are looking to get their project contributors
involved the various deployment projects I'm sure the additional input
and access to resources would be greatly appreciated.
> The incentive to contribute to Kolla is to have your project deployed from
> source or from binary in containers with full organized upgrade capability
> and full customization. If that isn't enough incentive, your right, I
> don't see people jumping on this.
>> Matt Riedemann
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev