Open Stack

On 4/23/16, 1:26 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:

>On 04/22/2016 08:27 PM, Steven Dake (stdake) wrote:
>>     * Repository per OpenStack and Infra component, e.g. one from nova,
>>     one for neutron and etc. - to contain all needed container images
>>     for running corresponding services in different topologies;
>>     * It should be possible to use other containers, not just docker,
>>     for example - rkt.
>>
>> I disagree strongly with the solution.  But you have stated a solution
>> without a problem.  I can tell you why I am anti-mult-repository ­ it
>> makes managing backports very difficult and time consuming.  It makes
>> repository management very difficult.  One error I think we made in
>> kolla-mesos was making a separate repository in the first place.  The
>> code should have just went straight into the kolla repo under the mesos
>> subdirectory just as ansible is today.
>
>If you look at Puppet and Chef deployment repositories, you will notice
>they separate each service out into separate repositories.
>
>Having separate repositories manes that they can version each service's
>deployment module/recipes separately from each other. You don't need to
>pull in patches to all of the Chef cookbooks for all services if you
>only need to apply a Keystone patch that the cookbook-openstack-identity
>repository applies and manages.
>
>This is the primary reason a multi-repository layout makes more sense to
>me.
>
>The single repo approach feels monolithic and the reverse of the
>nextgen-12-factor-app-microservice-the-world mentality that containers
>espouse.

Jay,

Thanks for a why.

I don¹t believe that the advantage of having separate repositories for
Kolla containers outweighs the negatives.  In Kolla's model, the keystone
example listed can be achieved by just only rebuilding the keystone
service.  Chef/puppet don't have image based deployment so they can't just
rebuild one - so separate versioning may make sense for those projects.
Kolla can build any container with any version identifier.

There is a two step process for releasing an alpha stream:
1.Tools/build.py --push --tag 2.0.0.1 nova

This will build everything nova related and push it to the docker registry.

2. Then apply a 2.0.0.1 tag to the existing containers in the docker
registry.
(exercise left to the reader)

This will make certain kolla can deploy 2.0.0.1 including old images and
new images.

Repo management and image management have little in common unless using
the docker registry build system.  That said, it may be possible to use
the docker registry build system with Kolla with some python scripting.
Kolla can output generated dockerfiles.

Just to be clear there are three reasons for the pushback on this
particular change:

1) We have 600+ containers - 600 git repositories for one project is
unmanageable:
https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=
0&q=kollaglue%2F&starCount=0


2) even if we pare that down to just the dockerfile.j2 that lands us with
115 repositories, still unmanageable.

3) Backporting from a split up repository to the stable branches becomes
real hard - effectively requiring a complete refactor and not allowing us
to follow the follows-stable policy for branching.  Doug Hellman (release
PTL) has said the release team will not tag zstreams (2.0.1 for example)
unless the stable maintenance team has signed off on it.  I assume this
means following the stable branch maintenance policy.  This change would
not allow us to follow that policy, which means we would not be able to
release z streams and maintain our software.  This point would need
negotiation with the release and stable teams.

Hope the context helps.

Now I understand where the idea of some kind of magic DSL that simplifies
the building of container dependencies (like base images and all nova
related containers in one file) is appealing for solving the
"-ETOOMANYREPOS problem".  I am unaware of any such thing already in
existence.   I have more pressing matters to spend my time on then
personally author a new DSL parser and build system along with a whole
slew of what gets built when logic.  That said I really like the idea -
and its growing on me by the minute.  It sounds like a fun project, which
I'd support in the context of serving as a PTL of Kolla if engineers
started developing it.  I have a good handle on the requirements of said
DSL and would be pleased to contribute to its design.

Regards
-steve

>
>Best,
>-jay
>
>__________________________________________________________________________
>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