You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com> on 2014/04/23 19:48:52 UTC
Cartridge agent for a VM without Java
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
Re: Cartridge agent for a VM without Java
Posted by chris snow <ch...@gmail.com>.
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)
<sh...@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 <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)
>> <sh...@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
Re: Cartridge agent for a VM without Java
Posted by damitha kumarage <da...@gmail.com>.
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) <
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 <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)
> > <sh...@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/
__________________________________________________________________
RE: Cartridge agent for a VM without Java
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
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 <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)
> <sh...@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
Re: Cartridge agent for a VM without Java
Posted by chris snow <ch...@gmail.com>.
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+Agent
>
> Thanks
>
>
> On Wed, Apr 23, 2014 at 11:18 PM, Shaheedur Haque (shahhaqu)
> <sh...@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
Re: Cartridge agent for a VM without Java
Posted by Imesh Gunaratne <im...@apache.org>.
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+Agent
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