stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chris snow <chsnow...@gmail.com>
Subject Re: Cartridge agent for a VM without Java
Date Fri, 25 Apr 2014 06:31:25 GMT
Hi Shaheed, this is an interesting problem!  IMHO, to be done
properly, Stratos should be responsible for managing the cartridge
proxy VM and the appliance VM lifecycles.  I'm not sure what the
impact would be on Stratos for a change like that.

On Thu, Apr 24, 2014 at 8:17 PM, Shaheedur Haque (shahhaqu)
<shahhaqu@cisco.com> wrote:
> Imesh, Chris,
>
> This is what I have in mind. Note: this is all rather speculative as I'm not yet sure
if the "nova boot" part below can be made to work yet....that would be a bit of a show-stopper...
>
> 1. We define an "appliance VM" as one that is too locked down to host a normal cartridge
agent.
> o       Lack of a JRE is one issue
> o       Lack of writeable file systems, Posix APIs and who-knows-what and so on might
be others.
>
> 2. Assume we have a "proxy cartridge" which can be instantiated cheaply many times.
> o       All standard Java code, sharing as much logic as possible from the current cartridge
agent.
> o       Probably all inside a single JVM with a threaded/event-based design.
> o       There is one proxy cartridge per appliance VM.
> o       Each proxy cartridge talks to Stratos on one side, and an appliance VM-specific
 plugin on the other.
>
> 3.  Figure out a “nova boot” command that boots a special “staging VM”.
> o       The nova boot command is what would be used for the appliance VM itself, except
that it...
> o       Has the appliance VM's (qcow2) image converted to a raw image and added as the
first block device
> o       Has one extra block device at the end, which is marked as the initial boot device.
> o       When initially booted, the staging VM contacts the proxy cartridge VM to set
up a new proxy cartridge with its IP address and so on.
> o       It the sets the default boot device to the first block device, and then reboots
>
> 4. The proxy cartridge which has been set up for the new appliance VM instance runs as
much of the lifecycle of a normal cartridge agent as it can via the plugin. The plugin is
always appliance VM-specific.
>
> If it can be made to work, the result will be that the VM that Stratos spins up *is*
the appliance VM, and we have a cartridge (proxy) agent managing it.
>
> Any better ideas? I think an upstream solution for this would be good as there seem to
be multiple cases of these "appliance VMs", but I realise that (3) in particular is so ugly
that this might never be a candidate for upstream...
>
> Thanks, Shaheed
>
> -----Original Message-----
> From: chris snow [mailto:chsnow123@gmail.com]
> Sent: 24 April 2014 19:37
> To: dev
> Subject: Re: Cartridge agent for a VM without Java
>
> It would be great to see a Cartridge Agent written in Google Go ;)
>
> On Thu, Apr 24, 2014 at 7:17 PM, Imesh Gunaratne <imesh@apache.org> wrote:
>> Hi Shaheed,
>>
>> This is interesting. Yes it is possible to implement a non Java
>> Cartridge Agent (CA). The protocols that it needs to support would be:
>>
>> 1. AMQP to talk to message broker
>> 2. Apache Thrift to talk to Complex Event Processor (CEP)
>>
>> In addition the VM should support Git to checkout deployment artifacts.
>>
>> We have written some basic descriptions on CA component architecture
>> here [1]. I will prepare more detailed information and let you know.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/STRATOS/4.0.0+Cartridge+Ag
>> ent
>>
>> Thanks
>>
>>
>> On Wed, Apr 23, 2014 at 11:18 PM, Shaheedur Haque (shahhaqu)
>> <shahhaqu@cisco.com> wrote:
>>>
>>> Hi,
>>>
>>> I have a VM I need to orchestrate under Stratos. Sadly, the VM is a
>>> bare-metal appliance which cannot run Java. I was thinking about
>>> creating some kind of a "remote cartridge" which could monitor the
>>> liveness and load of the VM via some legacy screen scraping etc. on
>>> one side, but yet presenting the cartridge agent interface into Stratos on the
other.
>>>
>>> I guess that others may have hit the same kind of situation before:
>>> is there any guidance on how such a remote/non-native cartridge might
>>> be approached?
>>>
>>> Thanks, Shaheed
>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PPMC Member, Apache Stratos
>
>
>
> --
> Check out my professional profile and connect with me on LinkedIn.
> http://lnkd.in/cw5k69



-- 
Check out my professional profile and connect with me on LinkedIn.
http://lnkd.in/cw5k69

Mime
View raw message