[openstack-dev] [ptl][kolla][release] Deploying the big tent
kevin.carter at RACKSPACE.COM
Wed Mar 30 02:25:57 UTC 2016
On 03/29/2016 04:46 PM, Emilien Macchi wrote:
> On Mon, Mar 28, 2016 at 9:16 PM, Steven Dake (stdake) <stdake at cisco.com> 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?
> Regarding our current model, I don't think we will (Puppet). See below
> this text.
>>> 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;)
>> 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?
> Puppet OpenStack, Chef OpenStack and Ansible OpenStack took another
> approach, by having a separated module per project.
> This is how we started 4 years ago in Puppet modules: having one
> module that deploys one component.
> Example: openstack/puppet-nova - openstack/puppet-keystone - etc
> Note that we currently cover 27 OpenStackc components, documented here:
> We have split the governance a little bit over the last 2 cycles,
> where some modules like puppet-neutron and puppet-keystone (eventually
> more in the future) have a dedicated core member group (among other
> Puppet OpenStack core members) that have a special expertise on a
> Our model allows anyone expert on a specific project (ex: Keystone) to
> contribute on puppet-keystone and eventually become core on the
> project (It's happening every cycle).
> For now, I don't see an interest to have this code living in core projects.
> Yes, there are devstack plugins, but historically, devstack is the
> only tool right now that is used to gate core projects (nova, neutron,
> Also, yes there are tempest plugins but it's because Tempest is the
> official tool to run functional testing in OpenStack.
> I would not be against having Kolla plugins, but I'm not sure this is
> the right approach for deployment tools, because there exists multiple
> of them.
Agreed. I also believe service projects have enough to worry about
without adding yet another workflow and set of bugs to their already
> I would rather investigate some CI jobs (non-voting for now) that
> would run in core projects and run Kolla / Puppet / whatever CI jobs,
> beside devstack.
> What do you think?
I personally think this is a great idea and it could potentially help
bring developers and deployers together which is a "win/win" in my opinion.
>> 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