Hi Shaheed, As I understand, the idea you bring is to provide some kind of proxy cartridge support for Apache Stratos, which would be useful for situations where the real would be cartridge instance has restrictions(like it cannot run normal cartridge agent). It this is the idea, then the solution cannot be Openstack specific(like you mention about nova boot in (3)). There is also some discussions in this list of writing cartridge agent using Python.
Damitha On Fri, Apr 25, 2014 at 12:47 AM, Shaheedur Haque (shahhaqu) < shahh...@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: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 > -- __________________________________________________________________ Damitha Kumarage http://people.apache.org/ __________________________________________________________________
