Open Stack

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
>>>> 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>

--

Kevin Carter
IRC: cloudnull