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:chsnow...@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 <im...@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) > <shahh...@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
