No worries about that. I also decided on XenServer, so I'm of the same mind you are about the best server for playing around with. Its too bad XMware doesn't have something that developers can use to toy around with, although with thier market-share I can see why they wouldn't care.
I'll research CentOS and Anaconda tonight. Thanks for pointing me in the right direction! Brian Topping wrote: > > Hi Mike, I don't really know anything about JeOS. It sounds interesting, > but I use CentOS almost exclusively. > > What you're talking about sounds a lot like Anaconda, though I doubt that > Anaconda exists on Debian platforms? > > As for VMWare, I really don't know too much about their products either. > XenServer did the trick for me and I stuck with that. > > Sorry I can't provide more info! > > On Sep 22, 2011, at 11:57 AM, mikevan wrote: > >> Brian, >> >> Another issue I'm seeing when creating virtual apps is because the >> applications are being deployed into JeOS, you need to identify all of >> the >> operating system dependencies of your application that aren't in JeOS. >> So, >> if Karaf needs a certain set of OS libraries, you have to explicitly >> state >> them. This seems like something that could be automated when creating >> the >> rpm. Do you know of any tools that take care of this for you? I was >> looking >> at VMWare's VStudio, but it looks like it requires you to have a VMWare >> system to connect to. Does that sound right to you? >> >> Mike Van >> >> >> >> Brian Topping wrote: >>> >>> 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. >>>> >>> >> >> >> ----- >> Mike Van >> Mike Van's Open Source Technologies Blog >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Karaf-rpm-distribution-tp3357636p3359232.html >> Sent from the Karaf - Dev mailing list archive at Nabble.com. >> > ----- Mike Van Mike Van's Open Source Technologies Blog -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-rpm-distribution-tp3357636p3359295.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
