Open Stack

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.

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.

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?


> 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



-- 
Emilien Macchi