On 03/29/2016 04:46 PM, Emilien Macchi wrote: > On Mon, Mar 28, 2016 at 9:16 PM, Steven Dake (stdake) <std...@cisco.com> > wrote: >> >> >> On 3/27/16, 2:50 PM, "Matt Riedemann" <mrie...@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 >>>> process. >>>> >>>> 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. >>>> >>>> Regards >>>> -steve >>>> >>>> >>>> >>>> _________________________________________________________________________ >>>> _ >>>> 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 >>>> >>> >>> 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. >> >> Matt, >> >> 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: > https://wiki.openstack.org/wiki/Puppet > > 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 > project. > > 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.
Agreed. > Yes, there are devstack plugins, but historically, devstack is the > only tool right now that is used to gate core projects (nova, neutron, > etc). > 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 full plate. > 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. >> >> Regards, >> -steve >> >>> >>> -- >>> >>> Thanks, >>> >>> Matt Riedemann >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> >> __________________________________________________________________________ >> 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 > > > -- Kevin Carter IRC: cloudnull __________________________________________________________________________ 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