projects

Alot of changes have gone into Polisher since my last update (eg the initial release). Most notably, the focus of Polisher has been changed and expanded, it now serves as a generic upstream project post-release processing tool, which can be used to configure any number of upstream projects w/ many various sources, and associate events with them to be triggered on releases. Polisher still works w/ the gemcutter API (namely the subscriptions / webhooks) as well as with gem2rpm, but now they are special cases in the generic upstream project management framework.

In the backend, Polisher is now based on Sinatra, which is far more lightweight and flexible than the previous solution, Rails. Rails is a powerful framework in itself, but I was looking for something small to help me establish the primary REST interface to the webapp.

Polisher also provides a nice DSL interface which can be used to define and run mass project / source registrations and trigger events in order to automate many various releases at the same time. I went through and picked several popular ruby-related packages from the current Fedora Repos, and wrote Polisher scripts for all of them, establishing several yum repositories for various Ruby related stacks.

Currently I have setup:

* stable - same packages that are currently in Fedora updates
* maintenance - later releases in the same major version branch of the packages currently in stable
* devel - packages that work w/ Ruby 1.9 (great resource)
* rawhide - all latest project versions

By tweaking the Polisher scripts and rpm spec file templates, the contents of these repos can be changed and new ones can be setup for any target software stack.

Any Fedora / yum user can simply point a yum repo entry towards any of those before running a yum update to get all the latest Ruby packages provided by that repo. Warning no functionality is guaranteed, there may currently be major breakage as Polisher and the scripts themselves are a work in progress. Furthermore, I'm in the process of setting up various Fedora based appliances, each pointing at a different Polisher generated repo by default. Any user can easily startup a VM on their local machine based off any of those appliances and instantly have Fedora w/ a complete Ruby stack for whichever version of Ruby they want to use. It's a work in progress, and I will have a link up soon to the downloadable images.

It would be awesome to get some help from anyone in the community that's interested in Ruby on Fedora (or any upstream project post-release processing on any flavor of Linux in general, as it's trivial to expand Polisher to handle any input/output package or repository format). It is a bit of effort to get Polisher scripts written for every Ruby related package, but if this thing starts rolling, I can see this as being a useful tool in the "upstream project to Fedora repo" process as mass parallel source releases can be triggered and handled easily in a committable / reproducible / reliable fashion.

Well that's it for now, be sure to note the many updates to deltacloud and many to my own projects, more on all of those in the near future.

Until next time, take it easy.

Just released RXSD (via github), a XSD <-> Ruby classes translator that makes use of Ruby's runtime introspection / reflection mechanisms to convert XML Schema Definitions to Ruby classes on the fly. Also supported is generating string Ruby class definitions (to be subsequently written to the filesystem) as well as a XSD metadata library / extendable builder interface to add output support for whatever language you need (python, c++, java, xml and other various formats, etc).

It's still pretty rough around the edges, I whipped it up in a little under a month (licensed under the LGPLv3+, so feel free to use it in proprietary apps, just make sure to publish the changes to RXSD itself back upstream), but most of whats there should be working. I'm going to keep hacking at it, mainly in part of a couple other things I'm doing, but also to improve features / support all around. This is my first project I'm hosting on github, so we'll see how that goes, from what I've seen it's pretty cool though (makes it very easy to share changes back / forth between projects).

As always, have at it!

I've just tossed up two new morsi.org subdomains. projects.morsi.org is my new hosting space for projects I'm working on. yum.morsi.org is a yum repository setup for my rpms, which right now only has Romic but I will be putting up Motel soon and more in the future. Putting it to use is as simple as creating /etc/yum.repos.d/morsi-org.repo with the following:

[morsi-org]
name=morsi-org
baseurl=http://yum.morsi.org/repos/$releasever/
enabled=0
gpgcheck=0

I found creating / hosting a yum repo to be remarkably easy. On my local machine, I created a 'yum' directory with a 'x86_64' subdir (create more for other architectures as needed, x86, noarch, etc) copied my rpms into it, and ran 'createrepo yum'.

Optionally create a domain, and on your webhost create a 'repos' subdir under the webroot dir. Create a subdirectory under this for the fedora release version your are building for (or whatever you are running by default), eg '11' as currently Fedora is on version 11.

scp the entire yum directory from your localmachine to 'repos/<release>' on your webhost. Finally create the yum.repos.d on any client you want to pull packages from your repo, and make sure to specify --enablrepo=<reponame> when running yum.

Optionally you may also want to change the .htaccess in your repository's webroot to alter the look of the yum index.

Simrpc is a simple rpc implementation written in Ruby, relying on Apache QPID for the transport mechanism. I modeled it after Apache QMF, though nowhere near as complex (simrpc is procedural based for example, with data structures only encapsulating data, and not methods), intended to be a placeholder until QMF becomes a bit more stable.

I was able to whip it up pretty quick, it only took me a week to write end-to-end, and thus I'm releasing it under the MIT License instead of my usual favorite, the AGPL. Eventually its a possibility that I might rewrite it in C++ as there isn't anything ruby-specific in it and I could easily then after write a Ruby wrapper (or any other).

Have at it!

Sometimes all you need is a good nights rest, I spent a considerable amount of time on this problem yesterday only to realize the solution was very simple.

Watch out when running the oVirt server on an vm, with your guest network set to the libvirt 'default' network on your host machine. The oVirt server depends on / will install libvirt and run libvirtd in your vm. Thus upon your first post-install restart, you will have the libvirtd default network interface, addressed at 192.168.122.1 running in your vm. Since various packets coming from the libvirt interface on your _host_ machine will have that same address, their responses will never make it back, rather they will goto the libvirt interface on your _vm_ and be subsequently discarded.

You most likely will notice this issue if you use tcpdump and you are receiving lots of ARP requests for your MAC from ip on your guest interface but no responses. Even running tcpdump on the libvirt network interface won't yield the responses, as even though their being sent there, that address just resolves to the local machine, and the kernel just processes the packets it already has.

To resolve this either just stop the libvirt daemon running on your oVirt vm (sudo service libvirtd stop) or use another network other than the "default" as one of the two for your libvirt server vm. Hope this helps!