Hi, On Tue, Sep 30, 2014 at 10:44 AM, Akila Ravihansa Perera <raviha...@wso2.com > wrote:
> Hi Chamila, > > Sounds like a good plan. Nice to see a testing plan in place for this. > Few suggestions on this; > > 1. You can use Kubernetes + Docker as the IaaS layer. It is still in > experimental state but we have fixed most of the issues. Anyway we > will have to test the Python cartridge agent with Kubernetes at some > point. > +1. IMO It is better if we first test the python cartridge agent with the OpenStack and then moved to the Kubernetes + Docker ? WDYT > > 2. You can use the sample event publishing tool to publish custom > events to topics. This tool was mainly developed to test the cartridge > agent. You can find it at [1]. I'm working on writing a Wiki page on > usage of this tool. Please let me know if you need help with it. > > [1] https://github.com/ravihansa3000/apache-stratos-samples I guess this sample event publisher based on the previous header based messaging. But we have changed that to the topic hierarchy based messaging and remove the header based messaging distinguished. I guess we need to change the the sample message publisher to support topic hierarchy based messaging publishing stuff. > > > Thanks. > > On Mon, Sep 29, 2014 at 10:19 PM, Chamila De Alwis <chami...@wso2.com> > wrote: > > Update on this task: > > > > Due to the time restriction, I momentarily switched to Vagrant as the > > instance spawning layer. Docker Stratos image configured with OpenStack > has > > a few restrictions, mainly not being able to connect to outside network. > > > > I created a Vagrant box with a mock payload parameters file and the > python > > cartridge agent. I'm in the process of further fine tuning the box to > > puppetize cartridge agent and the service setup. > > > > As an event listener tool, I started writing a small python script that > > takes the ip, port and topic to subscribe to as arguments. I'm planning > to > > complete this to take a set of events to accept and their respective > outputs > > as JSON to compare with to assert test success or failure. > > > > > > Regards, > > Chamila de Alwis > > Software Engineer | WSO2 | +94772207163 > > Blog: code.chamiladealwis.com > > > > > > > > On Mon, Sep 29, 2014 at 10:43 AM, Chamila De Alwis <chami...@wso2.com> > > wrote: > >> > >> + adding the reference to Stratos docker image blocking issue. > >> > >> Stratos in docker image not starting - > >> https://issues.apache.org/jira/browse/STRATOS-776 > >> > >> > >> Regards, > >> Chamila de Alwis > >> Software Engineer | WSO2 | +94772207163 > >> Blog: code.chamiladealwis.com > >> > >> > >> > >> On Mon, Sep 29, 2014 at 10:38 AM, Chamila De Alwis <chami...@wso2.com> > >> wrote: > >>> > >>> Hi, > >>> > >>> For $subject, the following can be proposed. > >>> > >>> The main test cases that are concerned with python cartridge agent > >>> development is discussed in the thread titled "MQTT Messaging + Python > >>> Cartridge Agent Testing Strategy". With the following setup I intend to > >>> cover the scenarios where messaging capabilities of the agent in an > end to > >>> end level has to be tested. > >>> > >>> The prerequisites that should be setup as the automated environment is > >>> mainly three parts. > >>> > >>> 1) Stratos installation - This is for the most part, a fixed element > >>> since the agent will be tested against a single released/will be > released > >>> version > >>> 2) Message broker + MySQL server - These are fixed and separate from > the > >>> Stratos element, to be reused over different installations > >>> 3) Puppet master (additional) > >>> > >>> The requirement is to subscribe to a cartridge and wait for the (ex: ) > >>> InstanceActivatedEvent to be published from the cartridge agent. > >>> > >>> IaaS > >>> === > >>> > >>> After a brief consideration over the different choices it seems, at > this > >>> moment, Docker is the best choice when it comes to spawning instances. > It is > >>> faster and easier to setup and maintain. Plus, there is already a VM > image > >>> with an OpenStack installation configured with Docker. > >>> > >>> > >>> Test Tool > >>> ====== > >>> For the messaging scope, initially a tool can be written to subscribe > and > >>> wait for a set of anticipated events within the member time out value, > and > >>> report success or failure of the test. > >>> > >>> > >>> Fixed Elements > >>> ========= > >>> Vagrant boxes with pre-installed Stratos, MB, MySQL and Puppet master > can > >>> be configured to be taken up when a test suite starts. Stratos Docker > image > >>> is having a blocking issue for the moment, therefore, Vagrant the next > best > >>> thing. > >>> > >>> > >>> > >>> This is the initial setup I have in mind. Hopefully we can build upon > >>> this to come up with a comprehensive test automation environment for > >>> stratos. WDYT? Any suggestions, corrections? > >>> > >>> > >>> > >>> > >>> Regards, > >>> Chamila de Alwis > >>> Software Engineer | WSO2 | +94772207163 > >>> Blog: code.chamiladealwis.com > >>> > >>> > >> > > > > > > -- > Akila Ravihansa Perera > Software Engineer, WSO2 > > Blog: http://ravihansa3000.blogspot.com > -- Best Regards, Gayan Gunarathne Technical Lead WSO2 Inc. (http://wso2.com) email : gay...@wso2.com | mobile : +94 766819985
