Open Stack

Vladimir,

thanks for bringing this up. It greatly correlates with the idea of
modularity. Everything related to an openstack release should be put in one
place and should be managed as a solid bundle on the master node. Package
repository is the first solution that comes to the mind and it looks pretty
good. Puppet modules, openstack.yaml and maybe even serialisers should be
stored in packages in the openstack release repository. And eventually
every other piece of our software should get rid of release-specific logic.

On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov <
vkozhukalov at mirantis.com> wrote:

> Dear colleagues,
>
> Currently, we install fuel-libraryX.Y package(s) on the master node and
> then right before starting actual deployment we rsync [1] puppet modules
> (one of installed versions) from the master node to slave nodes. Such a
> flow makes things much more complicated than they could be if we installed
> puppet modules on slave nodes as rpm/deb packages. Deployment itself is
> parameterized by repo urls (upstream + mos) and this pre-deployment task
> could be nothing more than just installing fuel-library package from mos
> repo defined for a cluster. We would not have several versions of
> fuel-library on the master node, we would not need that complicated upgrade
> stuff like we currently have for puppet modules.
>
> Please give your opinions on this.
>
>
> [1]
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218
>
> Vladimir Kozhukalov
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150909/83242e2a/attachment.html>