week 2: demo proposal

[kthfre]

Assignment Proposal

Title

Continuous integretion testing of node and service availability of promox instances

Names and KTH ID

• Minh Quang Nguyen ([email protected])
• Fredrik Gölman ([email protected])

Deadline

• Week 2

Category

• Demo

Description

Our demo will be performed in the context of physical servers that we access through a VPN.

We want to test the following

• Availablity of different nodes in a proxmox cluster
• Availabilty of different services on these nodes

Tools:

• Tailscale (VPN service/mesh network)

• Proxmox (VM virtualization)

• Jenkins (Automation Testing and Integration Testing)

• Option Currently Deciding

• Ansible (Testing Node instance, Update version ...etc)

• Terraform (Create Template for VM/docker/Container)

Backup plan:
In case we run into difficulties we deem unfeasible to overcome (the environment is not fully set up yet, and we are sort of short of time given the schedule) we discussed with the TA to create a rather simple web application involving either authentication functionality and a web form with input where validation would occur at the backend and perform integration tests by interacting with the browser and test frontend, backend, and potentially some database. We (and the TA) were unsure on whether the complexity level of this would be sufficient, but were asked to include it to have it commented on.

Relevance

We believe this is very rare compared to more conventional integration tests that may, for example, include a frontend and backend the the interactions between those two components. We also believe it is comparatively complex as it involves a lot of steps both in terms of setting up the environment and performing the tests. It also seem to fulfill a task that frequently would need to be performed manually by a system administrator otherwise. It is of course highly relevant to DevOps in general as it involves several CI tools such as Jenkins.

[javierron]

@kthfre Thanks for the proposal.

I'm a bit confused about what the demo is about. As I understand, you want to deploy a fairly complex backend, and automate availability testing and integration testing. Is this correct?

I feel that this proposal has too much focus on the deployment of the service rather than on the testing component. Can you describe in more detail how is the availability measured? Are you planning to use any specific tech/tool?

You also mention integration tests, can you describe in more detail how are these implemented? Any specific framework?

@algomaster99 @sofiabobadilla Feel free to follow up. Thanks!

[algomaster99]

Thanks for the proposal! And thanks, Javier, for feedback. I discussed this topic with them in person and then we concluded that integration test of the service is a good idea. One of the things we discussed was testing "collaboration on a document on the network", but availability is also good.

@kthfre if you can answer @javierron 's question, that would be great.

1. Can you describe in more detail how is the availability measured?

2. Are you planning to use any specific tech/tool?

3. can you describe in more detail how are these implemented? Any specific framework?

[bepp-boop]

Can you describe in more detail how is the availability measured?
At the moment, Fredrick and I try to use different technique that both revolve around Proxox and Jenkins server to test the availability of different container avaiblity inside of a node.
For me I used the API in the Proxmox to create a access token to allow Jenkin to access the enviroment of a specific nodes in the cluster. From here they able to request using http get to look though a json data system to surveilance the different container inside the node. Noted that this process is currently not work as there is a issues with SSL. It seem to be a common error that occur and I am currently trying to resolve it but is is not working. I was wondering if the TA know about this issues with Jenkin before.
https://stackoverflow.com/questions/24563694/jenkins-unable-to-find-valid-certification-path-to-requested-target-error-whil
Are you planning to use any specific tech/tool?
Currently we are only involve our self with Jenkin and other plugin that belong in it.
We also have network system like tailscale to create a VPN to make the Jenkin server accessible only to people that have access to it.
Proxmox is a virtualization OS that allow us to create cluster of machine and nodes with many container inside of individual nodes. It allow us to run different service with ease such as Jenkin and other container that we have to test the availability of it.

[bepp-boop]

Fredrik have a currently working pipeline which performs 3 stages:

Step 1: ssh into a server where it launches one of our python scripts to ping test the rest of the servers in the cluster (2 servers).
Step 2: ssh into a server where it through a python script of ours checks so that the corresponding software servers of a demo app of ours are running (1 process on each of the other 2 servers)
Step 3: read the junit test results and post the details in a slack channel (it does not separate the ping/process running tests but merely reports whether there is a failure or not)

[javierron]

@kthfre @bepp-boop
So let me summarize it to see if I understand correctly:

1. You deploy a microservice based app using proxmox and tailscale.
2. You create two scripts to test availability (one ping tests the servers, and one tests the app itself)
3. You automate the tests using Jenkins, so that these are run periodically.

This pipeline looks good.

I'm not sure where the junit tests fit, though. But I believe you can do without them in this demo.

Please reply to confirm that this is the specific pipeline expected in the demo.

[bepp-boop]

when you said micro based app, does that mean like poketbased and docker container? Would that be good?

[javierron]

@kthfre @bepp-boop

when you said micro based app, does that mean like poketbased and docker container? Would that be good?

I don't mean any tool in particular. I'm Just trying to understand the system that you will deploy and test. The specifics of the system are out of scope for this demo. I recommend to focus on the week's topic, which is testing automation and CI.

Can you confirm, or clarify that the three steps that I mentioned before are what you plan to present?

[kthfre]

@kthfre @bepp-boop So let me summarize it to see if I understand correctly:

1. You deploy a microservice based app using proxmox and tailscale.

2. You create two scripts to test availability (one ping tests the servers, and one tests the app itself)

3. You automate the tests using Jenkins, so that these are run periodically.

This pipeline looks good.

I'm not sure where the junit tests fit, though. But I believe you can do without them in this demo.

Please reply to confirm that this is the specific pipeline expected in the demo.

1. There is currently a very simple web application (for the sole purpose of the demo) which depend on both servers being up and running, and the actual server software running as a process on each respective server. Our automation pipeline wouldn't be specific to Proxmox and Tailscale in particular but could just as easily have been in a cloud environment and over the Internet, but this is what @bepp-boop setup looks like.
2. Yes. This is run through python scripts. The main reason for this is so that we could start working on the automation part immediately as the environment wasn't full set up and ready to go, but the same could have been achieved using bash commands from the pipeline. (there is no testing of the app itself as in unit tests or similar, just that the backend is serving the app as expected)
3. Yes. To argue for it being a realistic use case, one can perhaps envision some in-house development where this would be useful for the team handing the infrastructure and running the application. The results of the tests are, as previously mentioned, sent as notifications to a slack channel.

I don't believe Junit would conventionally be used for this kind of task, but we have wrapped our tests as python functions which return status codes which we perform unit tests on by passing the appropriate parameters. This was both due to the time shortage situation and the environment not being fully set up and the fact that parts of the tests are run remotely so that we could easily fetch the results in some format jenkins recognizes through scp.

[javierron]

@kthfre @bepp-boop
OK, it's very clear now. Good luck with the demo.