Suggestion how to enable caching
by Fabian Deutsch
Hey.
A couple of weeks ago I wrote about how I used squid to improve the build speed of images.
I think the minimal, easy to maintain and valuable solution is this simple config:
1. Setup squid on builders (default install on Fedora)
2. Add the following lines to the /etc/squid.conf
# Increase maximum size of cached objects and specify the cache_dir
# REMEMBER the ORDER
maximum_object_size 5 GB
cache_dir ufs /var/spool/squid 20000 16 256
3. Enable and start squid service
The service will only listen to connections from local networks, and will not proxy connections from public addresses.
The usage then is as follows:
Export http_proxy=127.0.0.1:3128 and all curl instances will pick up the proxy.
Similar parameters exist for other tools like the livemedia-creator too.
I am not familiar with writing a puppet class for this. But at least it is quite self contained.
Thoughts?
Geetings
fabian
9 years, 10 months
Re: proposing Alexander Wels as an ovirt-engine UI maintainer
by Vojtech Szocs
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Tal Nisan" <tnisan(a)redhat.com>, "Gilad Chaplik" <gchaplik(a)redhat.com>, "Vojtech Szocs" <vszocs(a)redhat.com>,
> "Kanagaraj" <kmayilsa(a)redhat.com>, "Daniel Erez" <derez(a)redhat.com>, "Tomas Jelinek" <tjelinek(a)redhat.com>, "Lior
> Vernia" <lvernia(a)redhat.com>
> Cc: infra(a)ovirt.org, "engine-devel" <engine-devel(a)ovirt.org>, "Alexander Wels" <awels(a)redhat.com>
> Sent: Tuesday, January 21, 2014 4:39:09 PM
> Subject: proposing Alexander Wels as an ovirt-engine UI maintainer
>
> Hello UI Maintainers,
>
> I would like to propose Alexander Wels as an ovirt-engine UI maintainer.
+1
>
> Alexander started his ovirt involvement more than a year ago,
> contributing over 100 patches (to 'master' alone), including the
> branding mechanism, Frontend refactoring (cleanup, unit-tests, requests
> retry mechanism, requests-aggregation mechanism), cross-GUI refresh
> synchronization and low-resolutions support.
>
> Your response would be appreciated.
>
> Thanks in advance.
>
> ----
> Regards,
> Einav
>
9 years, 10 months
Proposing Yedidyah Bar David as oVirt Hosted Engine Setup maintainer
by Sandro Bonazzola
Hi,
I would like to propose Yedidyah Bar David as oVirt Hosted Engine Setup co-maintainer.
Yedidyah contributed to oVirt Hosted Engine Setup since early design phase and contributed dozens of patches.
Your response would be appreciated.
Thanks in advance.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 10 months
Proposing Liron Aravot as an engine-core maintainer
by Tal Nisan
Hi core maintainers,
I would like to propose Liron Aravot as an engine-core maintainer.
Liron joined the oVirt project on June 2012, and has since contributed
over 170 patches to master (not counting backports to various stable
branches).
He has been instrumental in implementing oVirt's Backup API for external
providers, and has a been a driving force in improving flows regarding
SPM election and master domain reconstruction, handling OVF backups and
various concurrency issues both as a coder and a reviewer.
Your response would be appreciated.
Thanks,
Tal.
9 years, 10 months
proposing Arik Hadas as a maintainer of engine core
by Michal Skrivanek
Dear engine-core maintainers,
I'd like to propose Arik Hadas as a maintainer of oVirt engine backend
Since he started with oVirt project in October 2012 he was working in various areas in engine core, demonstrated his abilities with more than 200 patches merged to engine master alone. Tons of migration related fixes, refactoring of legacy code, but also new complex features including complementary patches in UI, REST and VDSM code (e.g. Live Snapshots with RAM, locking improvements for VM&Template operations)
Thanks in advance for your response.
Thanks,
michal
9 years, 10 months
Re: [ovirt-devel] Tools for developing and building oVirt.js project
by Sandro Bonazzola
Il 28/08/2014 21:00, Vojtech Szocs ha scritto:
>
>
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Mooli Tayer" <mtayer(a)redhat.com>
>> Cc: devel(a)ovirt.org
>> Sent: Tuesday, August 26, 2014 12:03:14 PM
>> Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js project
>>
>> Il 26/08/2014 09:38, Tomas Jelinek ha scritto:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Mooli Tayer" <mtayer(a)redhat.com>
>>>> To: "Greg Sheremeta" <gshereme(a)redhat.com>
>>>> Cc: devel(a)ovirt.org
>>>> Sent: Tuesday, August 26, 2014 9:17:20 AM
>>>> Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js
>>>> project
>>>>
>>>> Are we talking about using node as a development/test/packaging(minify etc
>>>> )
>>>> tool or having a runtime backend (site) on top of node?
>>>
>>> It is only devel environment (e.g. build dependency), not runtime.
>>
>>
>> If it's build dependency it's not just devel environment.
>
> Right, I messed up my comment above, sorry.
>
> Node.js can be (and typically is) used as both devel & build dependency
> for JavaScript projects.
>
>> We must ensure that all required build dependencies are available and
>> properly packaged for all supported distributions.
>
> Yes, fully agreed.
>
> Fedora already has some packages we could use, for example:
> http://koji.fedoraproject.org/koji/packageinfo?packageID=15154
> http://koji.fedoraproject.org/koji/packageinfo?packageID=15356
>
> However, there's one complication (as Greg mentioned before): npm (Node
> package manager) resolves Node-specific packages (esentially JavaScript
> artifacts) via HTTP access, so we'd need some infra to serve these, and
> for each such JS module:
> - either use existing package for that JS module, if one exists
> - or maintain package for that JS module on our own [*]
>
> [*] I understand that this is not what we want to do in general
I would add
- Ask supported distributions to provide needed rpms
>
> In other words, there would have to be some infra to support builds for
> JavaScript/Node.js projects, similar to existing infra to support builds
> for Java/Maven projects:
> - package for Node.js + npm
> - package for each JS module (likely problematic)
> - tool (existing Artifactory that serves Maven artifacts?) to serve
> JS modules via HTTP for npm to consume (maybe problematic)
>
Adding infra for above
> In any case, we can proceed with developing oVirt.js without requiring
> Node.js as a build dependency. I see two possible solutions here:
>
> 1, avoid using build tools like Traceur (ES6 -> ES5 transpiler)
> and UglifyJS (code compressor/obfuscator), just concatenate
> JS source files into resulting JS target file (either via
> command in Makefile or via some Maven plugin)
>
> PROS: no special build requirements
> CONS: can't use tools like Traceur
>
> 2, use build tools like Traceur and UglifyJS, commit resulting
> JS target file into source tree, maybe with git commit hook
> for this
>
> PROS: can use tools like Traceur
> CONS: storing target JS file in source tree
>
> 3, (?)
Use something simpler to package for compressing / minimizing like
http://yui.github.io/yuicompressor/ or any other tool like that at build time (nothing against Node.js at development time).
>
> What do you think?
>
> Note that this might work for small projects in short term.
>
> If we agree that JavaScript is the common base technology for
> oVirt frontend, not having well-established build environment
> (such as Node.js) will make it very hard to develop and maintain
> bigger JavaScript projects in the long term.
>
>>
>>
>>>
>>> I'd just like to point out that one thing is the development of the
>>> ovirt.js itself
>>> which is not going to be a big project and I can imagine also using less
>>> ideal (slower) tools for it's development.
>>>
>>> A completely different story will be when (if) we decide to use ovirt.js to
>>> develop some parts of the webadmin/userportal
>>> in javascript instead of GWT (or even rewrite the whole FE to JS) which
>>> will be a big project (set of projects).
>>>
>>> If we want to be effective in that effort, we will need good tools.
>>>
>>>>
>>>> From my perspective I can't stress enough how important is the separation
>>>> of ovirt UI part from the backend. I agree to everything Vojtech said
>>>> about
>>>> developing to the browser with java.
>>>>
>>>> Mooli.
>>>>
>>>> ----- Original Message -----
>>>>> ----- Original Message -----
>>>>>> From: "Vojtech Szocs" <vszocs(a)redhat.com>
>>>>>> To: devel(a)ovirt.org
>>>>>> Sent: Monday, August 25, 2014 11:13:38 AM
>>>>>> Subject: [ovirt-devel] Tools for developing and building oVirt.js
>>>>>> project
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> last week, we had "oVirt.js PoC" session and I mentioned the possibility
>>>>>> of using Node.js and related tools like npm to develop & build oVirt.js
>>>>>> project.
>>>>>>
>>>>>> I'd like to hear your opinion - what do you think about using Node.js in
>>>>>> context of developing & building JavaScript projects? (oVirt.js etc.)
>>>>>>
>>>>>> Obviously, I'm strongly biased towards Node.js because of its popularity
>>>>>> and therefore availability of various tools (npm packages) for
>>>>>> JavaScript,
>>>>>> for example: grunt (task runner), jslint/hint (code analyzer), uglifyjs
>>>>>> (minify/compress), karma (both one-time & continuous test runner),
>>>>>> traceur
>>>>>> (es6 -> es5 compiler), etc.
>>>>>>
>>>>>> My understanding is that any special-purpose JavaScript development tool
>>>>>> is typically implemented as module for Node.js (due to its popularity),
>>>>>> so I think it makes sense to use Node.js as a platform for JavaScript
>>>>>> development.
>>>>>>
>>>>>> There are also Java-based projects for JavaScript (post)processing like
>>>>>> wro4j, however these tend to be implemented by invoking JS tools (like
>>>>>> uglifyjs) from Java context via Rhino (JS engine for Java), for example:
>>>>>>
>>>>>> https://code.google.com/p/wro4j/source/browse/wro4j-extensions/src/main/j...
>>>>>>
>>>>>> (To me, developing JavaScript project with Java-centric tooling sounds
>>>>>> quite strange in general.)
>>>>>>
>>>>>> There's also webjars repository for hosting popular web resources for
>>>>>> use in Java applications (i.e. Maven artifact for uglifyjs etc.), but
>>>>>> this is just for easier dependency management from Java perspective
>>>>>> (JAR file as a distribution format for web resources):
>>>>>>
>>>>>> http://www.webjars.org/
>>>>>>
>>>>>> Overall, I'm in favor of using Node.js to manage all tasks related to
>>>>>> JavaScript development and build process. If you have any objections
>>>>>> or suggestions, I'd like to hear them!
>>>>>>
>>>>>> (I understand that Node.js essentially means new dependency with all
>>>>>> implications, but in this case, I think it's worth it. But this is
>>>>>> just me, so please share your opinions.)
>>>>>>
>>>>>> Thanks,
>>>>>> Vojtech
>>>>>
>>>>> I think most developers would agree that node.js is the tool of choice
>>>>> for
>>>>> JavaScript development.
>>>>>
>>>>> The thing we must carefully consider is that node.js uses its own package
>>>>> manager (npm -- much like maven), and unlike maven, tooling does not yet
>>>>> exist to deal with npm packages in an rpm environment.
>>>>>
>>>>> This isn't on the same level as adding a logging library or a collections
>>>>> library or something. I'd argue that dependencies don't get any heavier
>>>>> than this one. That is worrisome to me.
>>>>>
>>>>> Run 'yum list available |grep nodejs' on your machine to see which
>>>>> node.js
>>>>> packages are available. Note that I don't see karma or uglify available
>>>>> in
>>>>> either Fedora or Red Hat SCL (Software Collections) [1].
>>>>>
>>>>> [1]
>>>>> https://sochotni.fedorapeople.org/nodejs010-RHSCL-1-RHEL-6/Server/x86_64/...
>>>>>
>>>>> Greg
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 2 months
