Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

+1 to y'all :) We already have a blueprint to enable building Fuel packages with Perestroika: https://blueprints.launchpad.net/fuel/+spec/build-fuel-packages-using-perestroika Between that and packaging Perestroika itself as a self-sufficient tool that a developer can easily set up and run

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

I support this proposal but I just wanted to mention that we'll lose an easy way to develop manifests. I agree that manifests in this case have no difference with Neutron code, for instance. But anyway I +1 this, especially with Vova Kuklin's additions. On Thu, Sep 10, 2015 at 12:25 PM, Vladimir

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

+1 to Alex & Andrey. Let's just be very careful, and consider all the use cases before making a change. If we can have answers to all the use cases, then we are good to go. Important thing which we need to fix now - is to enable easy UX for making changes to environments after deployments. Like

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Alex, I absolutely understand the point you are making about need for deployment engineers to modify things 'on the fly' in customer environment. It's makes things really flexible and lowers the entry barrier for sure. However, I would like to note that in my opinion this kind on 'monkey

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Oleg, Alex gave a perfect example regarding support folks when they need to fix something really quick. It's client's choice what to patch or not. You may like it or not, but it's client's choice. On 10 Sep 2015, at 09:33, Oleg Gelbukh wrote: Alex, I absolutely

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Folks I have a strong +1 for the proposal to decouple master node and slave nodes. Here are the stregnths of this approach 1) We can always decide which particular node runs which particular set of manifests. This will allow us to do be able to apply/roll back changes node-by-node. This is very

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

I disagree from the development point of view. Now I just change manifests on Fuel node and redeploy cluster to apply that changes. With your proposal I'll need to build a new package and add it to a repo every time I change something. On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov <

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

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

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

I agree that we shouldn't need to sync as we should be able to just update the fuel-library package. That being said, I think there might be a few issues with this method. The first issue is with plugins and how to properly handle the distribution of the plugins as they may also include puppet

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Andrey, This change is going to make things even easier. Currently you don't need to build fuel-library package manually, Perestroika is going to do it for you. It builds necessary packages during minutes for every review request and packaging ci even tests it for you. You just need to make

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

I don't think juggling with repos and pull requests is easier than direct editing of files on Fuel node. Do we have Perestorika installed on Fuel node in 7.0? On Wed, Sep 9, 2015 at 3:47 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Andrey, > > This change is going to make things

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

No, Perestroika is not available on the Fuel master node and it is not going to be available in the future. But Perestroika is going to be re-worked so as to make it is possible to used separately from CI. It is gonna be a python application to make package building as easy for a developer/user as

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Alex, Regarding plugins: plugins are welcome to install specific additional DEB/RPM repos on the master node, or just configure cluster to use additional onl?ne repos, where all necessary packages (including plugin specific puppet manifests) are to be available. Current granular deployment

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Andrey, you have highlighted important case. I hope you agree that this case is not a blocker for the proposal. From the developer's point of view packages are awful and we should use raw git repos on every node. It could make developer's life way easier. But from architecture perspective it would

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

Hey Vladimir, > Regarding plugins: plugins are welcome to install specific additional > DEB/RPM repos on the master node, or just configure cluster to use > additional onl?ne repos, where all necessary packages (including plugin > specific puppet manifests) are to be available. Current granular

[openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

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