Hi, Today, I had a meeting with Michaël and had discussions about work items from the last week which basically includes: - Create a repository describing SSP and linking all other repos together. Also, update the documentation of other repositories. - Update the setup script to install the SSP Chart. - Do more research on readiness probe and try to implement it in Sugarizer Chart.
Problems experienced last week: None Here is a list of tasks that we have decided for this week: - Add a slack bot to publish events when Sugarizer Server deployment is installed/uninstalled. - Implement health checks in the app. PFA slack logs for reference. Next meeting is scheduled for next Monday. Regards, Nikhil
Michaël Ohayon 3:25 How are things going? Nikhil 3:25 PM It's going fine. What about you? 3:26 I hope international fights will open soon Michaël Ohayon 3:27 PM Regarding departure and arrival it may vary but let's cross fingers for your Japan flight :crossed_fingers: Nikhil 3:28 PM Yeah :crossed_fingers: Although my expected departure in mid october. I hope the situation approves by then 3:29 So the last week tasks were: - Create a repository describing SSP and linking all other repos together. Also, update the documentation of other repositories. - Update the setup script to install the SSP Chart. - Do more research on readiness probe and try to implement it in Sugarizer Chart. 3:29 The repo Sugarizer School Portal links the other SSP repos together: http://github.com/nikhilm98/sugarizer-school-portal Michaël Ohayon 3:29 PM I went through your docs at https://github.com/NikhilM98/sugarizer-school-portal 3:30 It's very nice Nikhil 3:30 PM Thanks :smile: 3:30 Also, I've moved the Setup script to this repo Michaël Ohayon 3:31 PM Having the links almost anywhere in the Readme made it really easier to follow Nikhil 3:31 PM The SSP Chart is hosted on this repo: https://nikhilm98.github.io/sugarizer-school-portal-chart/ (here: https://nikhilm98.github.io/sugarizer-school-portal-chart/index.yaml) (edited) Michaël Ohayon 3:31 PM I saw Lionel tweeting about it :grin: Nikhil 3:32 PM Lionel tweeted about Sugarizer Chart 3:32 He has not introduced SSP Server/Chart yet 3:33 He said it is his marketing strategy. He'll slowly introduce SSP in the coming weeks Michaël Ohayon 3:34 PM Yeah, it's a great idea to start with the local helm deploy :smile: :+1: 1 Nikhil 3:34 PM The SSP Setup script is now able to install SSP chart too: https://github.com/NikhilM98/sugarizer-school-portal/tree/master/scripts It runs these commands to install the SSP Chart: helm repo add ssp https://nikhilm98.github.io/sugarizer-school-portal-chart/; helm repo update; helm install ssp ssp/school-portal-chart -f charts/ssp-values.yaml; (edited) Michaël Ohayon 3:35 PM Yeah I saw your diff update, that can seem like a small patch but it's really worth it for new users Nikhil 3:35 PM Oops. I made a typo in the last message. Used "not" instead of "now" :sweat_smile: :grin: 1 3:35 Actually previously the setup script was in the SSP Charts repo. So there was no issue about fetching the chart code 3:37 But since now the setup script is in another repo. We would either need to pull the code from github or find some other way to host the chart. Pulling the code from github didn't look pretty to me since we need to install git for that. Also, there can be issues with git pull (Overwrites and merge conflicts) 3:37 So hosting the chart looked like a better approach to me Michaël Ohayon 3:38 PM Oh so it's why you had to host it like that okay got it Nikhil 3:39 PM Yeah. I've not hosted Sugarizer Chart yet. There was not too much requirement to host it (Since we require the values.yaml file anyways and it seems okay if you need to pull just one repository) Michaël Ohayon 3:40 PM Maybe one task in the future would be to list what to move on onto sugarizer org 3:40 Like repos and hosted things Nikhil 3:43 PM The Sugarizer Chart, SSP Chart, and SSP Server seem like independent projects in some way. The new SSP Repo contains the docs and the setup script. I was thinking of moving them all :sweat_smile:. Maybe Lionel could decide the necessary repos that the org requires. 3:44 So task 1 completed: Create a repository describing SSP and linking all other repos together. Also, update the documentation of other repositories. Task 2 completed: Update the setup script to install the SSP Chart. Task 3: Do more research on readiness probe and try to implement it in Sugarizer Chart. 3:44 https://sugarizer-workspace.slack.com/archives/C011B327MGX/p1594298624002500 Nikhil I was running tests for the health checks. I was thinking of using either httpGet or tcpSocket based health check. readinessProbe: httpGet: path: /api port: 8080 failureThreshold: 2 periodSeconds: 60 or readinessProbe: tcpSocket: port: 8039 failureThreshold: 2 periodSeconds: 60 Which configuration do you recommend? @Michaël Ohayon Show less Posted in #sugarizer-schoolportal | Jul 9th | View message 3:45 Also, we cannot check if the server is accessible over subdomain directly from inside the pod. The issue is that Kubernetes Reflector waits for the pod to be in Ready state before it can copy the certificate to the pod. So we'll only be checking if the server is able to accept traffic from inside the pod I installed a chart. The status turned out to be fine. Then I blocked the port. This is the result: 3:45 https://sugarizer-workspace.slack.com/archives/C011B327MGX/p1594298903006200 Nikhil image.png image.png Posted in #sugarizer-schoolportal | Jul 9th | View message 3:46 The status is running because the container is still running but the Ready state is 0/1 I think we can use this behaviour for the health check. The questions are: - How frequently should we run the health checks? - If we use kubectl to check status of a deployment. How frequently can we use kubectl command using SSP Server to check for the health status? - Where should we check for health status in the SSP Server? (When viewing a deployment info or on the dashboard -- If we check for health status on every dashboard refresh, it may take time to load the dashboard) Michaël Ohayon 3:46 PM Yeah, based on what I saw strangely most of time the frequency seemes to be somewhat high 3:47 I think we do not need to stress load our machine :smile: 3:47 Maybe 5 min could be acceptable? Nikhil 3:48 PM Yeah. 5 minute period sounds good to me. (edited) Michaël Ohayon 3:49 PM I saw that there are lots of monitoring tools outside kube mostly linked to prometheus 3:49 But that seemed to much overload for us 3:49 Maybe something like https://github.com/bitnami-labs/kubewatch 3:49 Would be sufficent 3:50 I did not test it so I do not know if that fits all we need 3:50 But that seems to be a nice starter Nikhil 3:51 PM Does it exposes an API too? To check for the status of the charts? Or does it interacts with Slack/Flock only? Michaël Ohayon 3:52 PM Seems to only push 3:52 Events 3:53 If you find a better tool that's great :slightly_smiling_face: Nikhil 3:53 PM Yes. There seems to be a option for webhook: https://github.com/bitnami-labs/kubewatch/blob/master/examples/conf/kubewatch.conf.webhook.yaml 3:53 I think it'll be simply pushing messages on this webhook Michaël Ohayon 3:54 PM Nice 3:54 you'll store them on mongo ? Nikhil 3:55 PM But it basically gets all the kubernetes events and sends a message on a websocket. 3:55 slack.png slack.png Michaël Ohayon 3:55 PM I guess you can filter things :thinking_face: Nikhil 3:56 PM I think it won't be much useful in our case. We want to develop a health check. We can ourself run the kubectl command using SSP Server to check for the logs. 3:57 The point is that we'll have to use their application then program our SSP Server to listen to this application (edited) 3:57 and update the health check on the basis of their logs. 3:58 It would take more memory plus it'll require more work. I think it'll be easier if we can ourself query for our pods and check their realtime health. Michaël Ohayon 4:01 PM Yeah, I liked the idea of notification though 4:01 So maybe we could add that Nikhil 4:02 PM I was thinking that we can program the Kubernetes deployment to run health check and update every 5 minutes. Then program the SSP Server to run a Kubectl query whenever the user open the SSP Server Home page. The kubectl query will check for the health of the deployment and update the "health" key in the deployments collection. If the health is good then health could be set to 1 else 0. 4:03 Yeah, I liked the idea of notification though You mean using Kubewatch or creating our own service for that? Michaël Ohayon 4:04 PM We can call slack directly Nikhil 4:07 PM Can we use Kubewatch just as external service? Just for the purpose of slack notifications? Michaël Ohayon 4:07 PM I think we can add a lib on the back Nikhil 4:09 PM As a required dependency or just additional library? Without actually including it in our project? Michaël Ohayon 4:10 PM In order to keep it simple I would add it on the package.json but only have triggers if env is having a slack api key Nikhil 4:14 PM I did not find the idea of using external tool for the purpose of slack notifications very good. I think we can create something of our own for that. We can create our own Slack app or something like that which will update the channel if a new deployment is installed/uninstalled/requested/approved? 4:14 What do you think about that? Michaël Ohayon 4:14 PM That's what I meant but I'm unclear I guess :upside_down_face: Nikhil 4:14 PM Even if we filter such notification. It won't look much pretty. slack.png slack.png Michaël Ohayon 4:15 PM Our node backend could trigger slack notification itself using a nodejs lib Nikhil 4:15 PM Yeah. Right! Michaël Ohayon 4:15 PM We do not need kubewatch thing 4:15 :slightly_smiling_face: Nikhil 4:15 PM Yes! 4:17 I think these tasks could be sufficient for this week.: Add a slack bot to publish events when Sugarizer Server deployment is installed/uninstalled. Implement health checks in the app. Michaël Ohayon 4:17 PM :ok_hand: 4:17 I'm trying to get Azure accesses 4:17 I have AWS 4:18 Maybe we'll need to think about replacing our gke requirements with equivalents Nikhil 4:19 PM Yeah. First we need to test and get the SSP working with other providers. Then we can add if else statements to handle other providers by simply modifying the values file. :+1: 1 Michaël Ohayon 4:21 PM I'll try to get everything setup fast Nikhil 4:21 PM Okay! 4:21 Should we end this meeting? Michaël Ohayon 4:23 PM Yeah I guess :slightly_smiling_face: ! 4:23 Thanks for all the good work :thumbsup: :smile: 1 Nikhil 4:23 PM Have a nice day!
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
