Yes, I see where you guys are going with this. It does seem very valuable to have an RPM that has all the proper dependencies for the raw environment so that something like 'yum' can pull in everything, including Java, for someone that wants to run Karaf / Cellar / Cave. At that point, what I was talking about kicks in.
Would it also be valuable to create an Anaconda script so raw machines (whether virtual or on bare metal) could be generated from scratch in an unattended manner? It's a little more obscure and a little less direct than downloading a VM from the net and booting it, but Anaconda scripts are short and readable, allowing for security-conscious admins to understand exactly what is being built and from where. It would also provide the ability for the VM creator to tune what version of the OS was put on the VM image in a predictable manner, or even generate a batch of different VMs, each with a different underlying OS. In other words, the Anaconda script would serve for the building of the VMs for distribution, as well as provide a source for people to build their own. Another consideration is the hosting of the RPM artifacts in an accessible yum repository. Once a VM was set up and cloned like this, I'm probably not going to want to replace it when minor releases to Karaf come out, but would rather that it can update itself with new RPMs via 'yum update' or equivalent. Doing so would ideally include having that VM set up with the yum repo already enabled. One of the typical problems with jpackage.org is the RPM releases there lag pretty far behind the actual core software release, and if they could be done together, it might make a pretty big impact on people's use. If I understand it correctly, hosting a yum repo is very similar to hosting a Maven repo, including the availability of optional tools for those that are so inclined. On Sep 22, 2011, at 10:25 AM, mikevan wrote: > Thanks for all of your suggestions. To be clear, I'm talking about creating > an RPM of vanilla Karaf. If folks want to add thier application bundles to > it, then I feel they should repackage thier own RPM. > > Stephen, > > I looked at three vendors for creating and deploying my vapp. The basic > item I considered was the ability to deploy on a low-end, but modern laptop. > I want other folks to be able to duplicate what I did, so the minimum > installation I found was 2 low-end laptops. And by low-end, I mean I went > into best buy and bought the least expensive laptops they had. I ended up > with a Dell Inspiron and a Toshiba Satellite. > > I reviewed three different cloud vendors: Citrix XenServer, VMWare > Hypervisor, and Suse Studio. VMWare Hypervisor was ruled out because it > requires a gigabit ethernet controller or a nic card capable of transmitting > 1B/s. Despite this, I attempted to install it on my Toshiba Satellite, and > it did not have drivers for my ethernet card. Suse Studio seemed viable, > but it required an rpm of the applications I wanted to install in my > virtuall appliance. XenServer did completely install on my Toshiba > Satellite, and I am now configuring it. Because XenServer installed, I > chose to move forward with that option. > > I hope that answers your question. Moving forward, my plan is to create > rpm's containing Karaf, Cellar and Cave, and use those to create a virtual > appliance. Because rpm's appear to be the deployment mechanism of choice > for deploying applications to virtual appliances, I asked if the Karaf group > would consider creating distributions in .rpm's. > > > > Stephen Evanchik wrote: >> >> Hi Mike, >> >> On Wed, Sep 21, 2011 at 11:38 PM, mikevan <[email protected]> >> wrote: >>> Currently, we distribute Karaf as a tar.gz, and a zip. I'm finding that >>> .rpm's are also a useful deployment mechanism. In fact, when creating >>> virtual appliances, I continue seeing rpm's as an option (sometimes the >>> only >>> option) for uploading applications into the Vapp. With this in mind, >>> should >>> we be creating .rpm distributions of Karaf, Cellar, Cave, and the >>> Webconsole? >> >> I work on a Karaf based product that ships as an RPM. It has been >> great for the initial installation but maintenance has been >> challenging to say the least. Respinning an RPM to do a patch or minor >> release is not desirable and the product is searching for alternative >> installation mechanisms. >> >> As an aside, since you mention vApp: are you using VMware Studio? I >> know that it has a"limitation" that makes consuming non-RPM >> installation units difficult. >> >> >> Stephen >> >> >> -- >> Stephen Evanchik >> http://stephen.evanchik.com >> > > > ----- > Mike Van > Mike Van's Open Source Technologies Blog > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Karaf-rpm-distribution-tp3357636p3358946.html > Sent from the Karaf - Dev mailing list archive at Nabble.com. >
