karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Topping <topp...@codehaus.org>
Subject Re: Karaf rpm distribution?
Date Thu, 22 Sep 2011 16:06:27 GMT
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
>>>> &lt;mvangeertruy@comcast.net&gt;
>>>> 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.
> 


Mime
View raw message