+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 standard configuration management allows you to do. Namely, being able to: a) modify params on settings tab b) modify templates / puppet manifests and apply changes easily to nodes. Now, we can do b) easy and just click Deploy button or run two-three commands [1]. a) requires changes in Nailgun code to allow post-deployment modification of settings (we currently lock settings tab after deployment). If we switch to package installation and this workflow (change to manifests + 2-3 commands to rsync/run puppet on nodes) will become a nightmare - then we'll need to figure out something else. It has to be easy to do development and use Fuel as configuration management tool. [1] https://bugs.launchpad.net/fuel/+bug/1385615 On Wed, Sep 9, 2015 at 8:01 AM 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Mike Scherbakov #mihgen
__________________________________________________________________________ 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