+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 locally (which we also need a blueprint for), I think we'd have enough tools to distribute fuel-library to target node as packages both in production, and, without too much additional effort, as part of development workflow. -DmitryB On Fri, Sep 11, 2015 at 10:59:40PM +0300, Andrey Danin wrote: > 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 Kuklin <vkuk...@mirantis.com> > wrote: > > > 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 important from operations perspective. > > 2) We can decouple master and slave nodes manifests and not drag new > > library version onto the master node when it is not needed. This allows us > > to decrease probability of regressions > > 3) This makes life easier for the user - you just run 'apt-get/yum > > install' instead of some difficult to digest `mco` command. > > > > The only weakness that I see here is on mentioned by Andrey. I think we > > can fix it by providing developers with clean and simple way of building > > library package on the fly. This will make developers life easier enough to > > work with proposed approach. > > > > Also, we need to provide ways for better UX, like provide one button/api > > call for: > > > > 1) update all manifests on particular nodes (e.g. all or only a part of > > nodes of the cluster) to particular version > > 2) revert all manifests back to the version which is provided by the > > particular GA release > > 3) <more things we need to think of> > > > > So far I would mark need for simple package-building system for developer > > as a dependency for the proposed change, but I do not see any other way > > than proceeding with it. > > > > > > > > On Thu, Sep 10, 2015 at 11:50 AM, Sergii Golovatiuk < > > sgolovat...@mirantis.com> wrote: > > > >> 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 <ogelb...@mirantis.com> wrote: > >> > >> 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 > >> patching' is actually a bad practice for any environments other than dev > >> ones. It immediately leads to emergence of unsupportable frankenclouds. I > >> would greet any modification to the workflow that will discourage people > >> from doing that. > >> > >> -- > >> Best regards, > >> Oleg Gelbukh > >> > >> On Wed, Sep 9, 2015 at 5:56 PM, Alex Schultz <aschu...@mirantis.com> > >> wrote: > >> > >>> 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 > >>>> deployment > >>>> approach makes it easy to append specific pre-deployment tasks > >>>> (master/slave does not matter). Correct me if I am wrong. > >>>> > >>>> > >>> Don't get me wrong, I think it would be good to move to a fuel-library > >>> distributed via package only. I'm bringing these points up to indicate > >>> that there is many other things that live in the fuel library puppet path > >>> than just the fuel-library package. The plugin example is just one place > >>> that we will need to invest in further design and work to move to the > >>> package only distribution. What I don't want is some partially executed > >>> work that only works for one type of deployment and creates headaches for > >>> the people actually having to use fuel. The deployment engineers and > >>> customers who actually perform these actions should be asked about > >>> packaging and their comfort level with this type of requirements. I don't > >>> have a complete understanding of the all the things supported today by the > >>> fuel plugin system so it would be nice to get someone who is more familiar > >>> to weigh in on this idea. Currently plugins are only rpms (no debs) and I > >>> don't think we are building fuel-library debs at this time either. So > >>> without some work on both sides, we cannot move to just packages. > >>> > >>> > >>>> Regarding flexibility: having several versioned directories with puppet > >>>> modules on the master node, having several fuel-libraryX.Y packages > >>>> installed on the master node makes things "exquisitely convoluted" rather > >>>> than flexible. Like I said, it is flexible enough to use mcollective, > >>>> plain > >>>> rsync, etc. if you really need to do things manually. But we have > >>>> convenient service (Perestroika) which builds packages in minutes if you > >>>> need. Moreover, In the nearest future (by 8.0) Perestroika will be > >>>> available as an application independent from CI. So, what is wrong with > >>>> building fuel-library package? What if you want to troubleshoot nova (we > >>>> install it using packages)? Should we also use rsync for everything else > >>>> like nova, mysql, etc.? > >>>> > >>>> > >>> Yes, we do have a service like Perestroika to build packages for us. > >>> That doesn't mean everyone else does or has access to do that today. > >>> Setting up a build system is a major undertaking and making that a hard > >>> requirement to interact with our product may be a bit much for some > >>> customers. In speaking with some support folks, there are times when > >>> files > >>> have to be munged to get around issues because there is no package or > >>> things are on fire so they can't wait for a package to become available > >>> for > >>> a fix. We need to be careful not to impose limits without proper > >>> justification and due diligence. We already build the fuel-library > >>> package, so there's no reason you couldn't try switching the rsync to > >>> install the package if it's available on a mirror. I just think you're > >>> going to run into the issues I mentioned which need to be solved before we > >>> could just mark it done. > >>> > >>> -Alex > >>> > >>> > >>> > >>>> Vladimir Kozhukalov > >>>> > >>>> On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz <aschu...@mirantis.com> > >>>> wrote: > >>>> > >>>>> 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 code that needs to be installed on the other nodes for a > >>>>> deployment. > >>>>> Currently I do not believe we install the plugin packages anywhere > >>>>> except > >>>>> the master and when they do get installed there may be some post-install > >>>>> actions that are only valid for the master. Another issue is being > >>>>> flexible enough to allow for deployment engineers to make custom changes > >>>>> for a given environment. Unless we can provide an improved process to > >>>>> allow for people to provide in place modifications for an environment, > >>>>> we > >>>>> can't do away with the rsync. > >>>>> > >>>>> If we want to go completely down the package route (and we probably > >>>>> should), we need to make sure that all of the other pieces that > >>>>> currently > >>>>> go together to make a complete fuel deployment can be updated in the > >>>>> same > >>>>> way. > >>>>> > >>>>> -Alex > >>>>> > >>>>> > >>> > >>> __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > > > > > > -- > > Yours Faithfully, > > Vladimir Kuklin, > > Fuel Library Tech Lead, > > Mirantis, Inc. > > +7 (495) 640-49-04 > > +7 (926) 702-39-68 > > Skype kuklinvv > > 35bk3, Vorontsovskaya Str. > > Moscow, Russia, > > www.mirantis.com <http://www.mirantis.ru/> > > www.mirantis.ru > > vkuk...@mirantis.com > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > -- > Andrey Danin > ada...@mirantis.com > skype: gcon.monolake > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
