Good thoughts. my 2c: We should absolutely enable people to develop and iterate over code changes locally. If we ever come to a point where the "golden jenkins job on a remote server for building custom ISO" is the only way to test changes, that won't be acceptable.
I think we are on the same page though As both Dmitry and Andrew mentioned "hacking changes into an already deployed env". We should go ahead and create instructions/scripts for that Thanks, Roman On Wednesday, January 15, 2014, Dmitry Borodaenko <[email protected]> wrote: > Having a reliable and *repeatable* way to update a deployed fuel > master node from local nailgun and fuel-library (and astute and ostf) > changes would be a very nice thing to have. Reducing the number of > cases where an ISO rebuild is needed to test a change will certainly > help speed up development, it might also increase the amount of > testing done by developers before changes are published and merged. > > As Andrew has already mentioned, Fuel is not the only thing present on > the ISO that may need to be changed during development. There's > nailgun DB, CentOS and Ubuntu package repositories, packages installed > on the fuel-master itself, the bootstrap image. We need a way for > developers to test changes to all of these, two. > > And to reiterate the concerns I've mentioned yesterday, even if you > have a post-deployment update tool that can take care of updating all > types of components on a deployed master node (which I suspect is a > bit more than what DmitryP is talking about), that tool still cannot > be the only option available to developers. If incremental updates are > the only way you test things, the difference between that and the > production deployment process (installing fuel master from a new ISO > image and installing all components from packages) will make you miss > all ISO and packaging specific bugs until much later when QA picks it > up. > > So yeah, we need to keep the ability to build our own custom ISO > images. And we need to improve it, too. I think we need to bring the > OSCI packaging process closer to Fuel development and make it open to > external contributions, so that anyone can build their own packages > and test them by including them in a custom ISO before submitting a > review request to OSCI. It would also help take some load off the OSCI > team and let them focus more on improving their tools rather than > dealing with internal tickets asking for package rebuilds. > > BTW here's how WikiMedia combines git-buildpackage with gerrit: > https://wikitech.wikimedia.org/wiki/Git-buildpackage > > -DmitryB > > > On Wed, Jan 15, 2014 at 10:01 AM, Andrew Woodward <[email protected]> > wrote: > > +1 to Dmitry P, I much prefer hacking my changes into a deployed env over > > waiting for an ISO to build, most of the time Its trivial and results in > > more stable code. The only hard thing to do is to inject deb packages > since > > the CentOS master lacks the tools to rebuild the repo metadata. > > > > > > On Wed, Jan 15, 2014 at 7:47 AM, Dmitry Pyzhov <[email protected]> > wrote: > >> > >> My vision about packages versus development: > >> > >> We should pack nailgun and fuel with OSCI tools. For development we > should > >> update files in place on pre-deployed nodes. And we should have jenkins > job > >> for building custom isos from branches. And we should say good-bye to > local > >> iso build from the sources. > >> > >> So developer should test changes on pre-deployed node (we should create > >> instruction for that). And if he or she wants to be absolutely sure > there is > >> an option to test on custom iso. > >> > >> We are moving toward this process, but have lack of resources in OSCI > >> team. > >> > >> > >> > >> On Wed, Jan 15, 2014 at 8:28 AM, Oleg Gelbukh <[email protected]> > >> wrote: > >>> > >>> JFYI, this thread contains multiple opinions about packages > applicability > >>> to mass scale in production: > >>> > >>> > http://lists.openstack.org/pipermail/openstack-dev/2014-January/023628.html > >>> > >>> Main idea is that at scale packages are too granular to be managed > >>> effectively. However, packages could be used to create base overcloud > images > >>> with all benefits Alexander mentioned (i.e. verisioning etc). > >>> > >>> FWIW, OSCI project did some job to make packaging a part of development > >>> process in the past. It could continue down that path. > >>> > >>> -Oleg > >>> > >>> > >>> On Wed, Jan 15, 2014 at 2:50 AM, Dmitry Borodaenko > >>> <[email protected]> wrote: > >>>> > >>>> Unless we move away from package based deployment altogether (which > >>>> btw I think would be a bad idea: I agree with Aleksandr and Ivan that > >>>> packages are more suitable for production), we have to make generation > >>>> of rpm and deb packages a part of our development process. I think the > >>>> best way to achieve that is have a public git-buildpackage repository > >>>> for each package we build, and use mr/myrepos to make rebuilding all > >>>> these packages a part of make iso, as an alternative to "make > >>>> deep_clean". > >>>> > >>>> Having one deployment process for development and another process for > >>>> production is even worse than picking the wrong process. It would push > >>>> discovery of packaging-related bugs from the very beginning of the > >>>> development cycle (before the change is even pushed to gerrit) towards > >>>> the very end of the cycle (after a release candidate build was passed > >>>> to QA). It is widely accepted that the cost of fixing a bug grows > >>>> exponentially related to the time elapsed since the bug was > >>>> introduced. > >>>> > >>>> My 2c, > >>>> -DmitryB > >>>> > >>>> > >>>> On Tue, Jan 14, 2014 at 1:13 PM, Ivan Kolodyazhny <[email protected]> > >>>> wrote: > >>>> > RPMs is good for production use. For development process we need to > >>>> > specify > >>>> > some workflow and create guidelines like a Nailgun docs to easy get > >>>> > development environment. > >>>> > > >>>> > > >>>> > -- > >>>> > Regards, > >>>> > Ivan "e0ne" Kolodyazhny > >>>> > > >>>> > On Tu
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
