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
