Hi, Today, I had a meeting with Michaël and had discussions about work items from the last week which basically includes: - Do research on how to implement HTTPS on the cluster. - Deploy the SSP into Kubernetes
Problems experienced last week: - Unable to open port 8039 using Ingress Nginx. It was fixed on doing some research and modifying the values file. - Problem sharing TLS secret among different namespaces. It was fixed by using Kubernetes Reflector. Here is a list of tasks that we have decided for this week: - Update nodejs-helm and give it a feature to add --all-namespaces in its API calls. - Install the Helm charts using SSP in the default namespace. - Research about the backup and restore strategies for the mongodb-replicaset. - Finalise the SSP Chart beta, add documentation and add it on GitHub. PFA slack logs for reference. Next meeting is scheduled for next Monday. Regards, Nikhil
Michaël Ohayon 1:52 PM -- 1:52 New meeting :slightly_smiling_face: 1:52 Hey Nikhil! Nikhil 1:52 PM Hello @Michaël Ohayon :smile: Michaël Ohayon 1:53 PM How is it going? Nikhil 1:55 PM I'll be moving to my home on 18th -- 500 km by cab. I don't have proper LAN connection at home, may have to depend on 4G connection for a day or two before the LAN gets set-up at home. I'll contact the vendor today for the wired connection. Hopefully they will set it up before I reach home. 1:55 Currently I'm staying at the college. 1:56 Okay, so the last week tasks are: Do research on how to implement HTTPS on the cluster. Deploy the SSP into Kubernetes 1:58 I have created a Helm chart for SSP. I have not yet pushed the repository, I was thinking of adding a proper documentation before updating that. The helm chart is live at https://sugarizer.tools You can use this deployment to request and create new deployment on the cluster. 1:58 I have shared with you the admin username and password that can be used to log into sugarizer.tools Michaël Ohayon 1:59 PM Yes thanks I've been playing with it a little, that is very nice to be able to use the same ressource pool :smile: 1:59 How did you get past the helm exposure ? Nikhil 2:00 PM What do you mean by helm exposure exactly? Exposing the cluster kubectl api to helm? (edited) Michaël Ohayon 2:01 PM Yes 2:01 :smile: Nikhil 2:01 PM I created a service account and gave it limited permission. 2:01 Let me share you the permissions what I granted to the service account. 2:02 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ssp-clusterrole-{{required "sspNamespace not defined" .Values.sspNamespace}} namespace: {{required "sspNamespace not defined" .Values.sspNamespace}} rules: - apiGroups: [""] resources: ["pods", "nodes", "configmaps"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["services", "secrets", "namespaces"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: ["networking.k8s.io"] resources: ["networkpolicies"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: ["k8s.nginx.org"] resources: ["virtualservers"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: ["cert-manager.io"] resources: ["certificates", "issuers"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] 2:03 These are the permissions I have to the SSP cluster. Michaël Ohayon 2:03 PM kubectl is auto detecting the endpoint then ? 2:03 :thinking_face: Nikhil 2:03 PM Yeah Michaël Ohayon 2:03 PM Oh nice Nikhil 2:03 PM I used Microsoft's Helm Web API for reference: https://github.com/dunefro/helm-web-api 2:03 They were doing something similar. 2:04 Also, we faced issue with using HTTPS. Cert-manager was able to generate only 10 certificates in 3 hours plus it had some other limitations. 2:05 I used Kubernetes-Reflector to use the same TLS certificate for all the deployments. 2:05 I use a wildcard name in the certificate. Michaël Ohayon 2:06 PM Yes I remember that was one big limitation of kube 2:06 Is the sugarizer.tools still using the staging env of letsencrypt? Nikhil 2:08 PM I was having issues with Kubernetes-Reflector, I contacted the developers of the Kubernetes Reflector to show me how we can share TLS certificate on different namespaces. Their documentation did not mentioned what we needed, they showed me how we can do that personally on Slack (their workspace). :clap: 1 2:08 Is the sugarizer.tools still using the staging env of letsencrypt? Yes. It's still using the Staging API. Michaël Ohayon 2:09 PM Very nice work :smile: This issue could have taken so much longer to find a solution Nikhil 2:10 PM Thanks :smile: 2:10 So the cluster is on HTTPS now. SSP is inside the cluster. 2:12 The current issues are. We need to update nodejs-helm and give it a feature to add --all-namespaces in its api calls. Specify namespace=default while installing the Helm charts since it currently installs the charts in the schoolportal namespace. 2:13 We also need to update the documentation to make the setup process more clear. Michaël Ohayon 2:13 PM Maybe a stupid question but what are the limitations of having each school under their own namespace? :thinking_face: Nikhil 2:16 PM Each school under its own namespace. -- It has no limitations currently. Previously we had the limitation that we were not able to access the TLS certificate from other namespace. Currently the helm charts for all the schools are installed in schoolportal namespace instead of default namespace. -- Only helm charts data is in the schoolportal namespace, the schools are still present in their own namespace. Michaël Ohayon 2:16 PM Oh ok I get it 2:16 Perfect Nikhil 2:17 PM I we delete the schoolportal namespace, the helm chart data of the deployments might get damaged. I'm not sure. But if we deploy the charts in the default namespace, it will be safer even if SSP is deleted (I guess :sweat_smile:) (edited) Michaël Ohayon 2:18 PM I guess there are two approachs on that, someone could say that having these data on their own namespace is also a good thing. (edited) 2:18 But since its only chart definition let's go on default namespace Nikhil 2:19 PM Yeah 2:19 So after the above mentioned issues are fixed, maybe we can move on creating an Ansible package for the SSP. What do you think? Michaël Ohayon 2:21 PM Yeah exactly 2:21 Hardest part today is to create cluster, deploy ssp Nikhil 2:21 PM Ansible package plus a step by step documentation for manual setup. Since we cannot depend on the Ansible setup because it might show errors to some people. Having a step by step setup doc will be reliable in this case. (edited) Michaël Ohayon 2:21 PM And things like that 2:22 Do not forget that pushing your actual code may require some time since you may want to do some modifications :upside_down_face: Nikhil 2:23 PM What kind of modifications? Which repo? Michaël Ohayon 2:23 PM Not sure but maybe you would want to clean up things or remove comments 2:23 If it's just push it should be quick :smile: Nikhil 2:24 PM You mean the SSP Chart repo. Right? Michaël Ohayon 2:24 PM yep Nikhil 2:25 PM Yeah. I does not requires much cleaning, but I need to write a documentation so that the repo makes sense :sweat_smile: Michaël Ohayon 2:25 PM Next big subject I guess will be backup/restore 2:25 After all that deploy thing Nikhil 2:26 PM Yeah. Almost forgot about that Michaël Ohayon 2:26 PM Like scheduling mongo export and ingest script 2:26 And also charts saving 2:27 It should not be too complicated. Recovery may be launched by hand 2:27 But backup has to be autonomous :slightly_smiling_face: Nikhil 2:28 PM The data about the chart name its database name will be stored in the ssp database. Do we really need to backup the chart manifest data? I think we only need to backup the mongodb replicaset data. Michaël Ohayon 2:29 PM I see two error that may occur 2:29 Broken mongodb 2:29 or Broken cluster :smile: Nikhil 2:29 PM If we are able to restore the SSP data, then we will have the list to deployments and the approved deployments. After that we just have to deploy the approved deployments. (edited) Michaël Ohayon 2:30 PM Ok perfect 2:30 That's a valid way for me :slightly_smiling_face: Nikhil 2:30 PM Okay :grin: 2:32 So we don't need to backup the chart manifests. If we can backup the database data, it should be enough. To backup the database, we have two options, to backup the persistent volumes or to use mongodump to backup the data. Michaël Ohayon 2:32 PM I would rather go for a mongodump since it would I guess make some consistancy checks :+1: 1 Nikhil 2:32 PM Btw where do you think we will be storing the backup data? Michaël Ohayon 2:33 PM Maybe push it under some google alternative to S3 2:33 Their cloud storage thing 2:34 Best would be to find a tool that support google and s3 2:34 So we could store whereever we want Nikhil 2:35 PM Okay, so store it into some cloud storage or something. I'll do some research on that. On the last research, I could see that some people were trying to store the data into another compute instance. They were using the mongodb from another compute instance and were running mongoexport from there while connecting with the cluster mongodb. 2:36 Maybe there are some libraries that create mongoexport and store them in some cloud storage. I'll have a look later. Michaël Ohayon 2:37 PM That's a good approach :smile: Nikhil 2:39 PM Which one? The one that includes using another compute instance? But that way one compute instance will be reserved for the backup job, looks kinda expensive. Michaël Ohayon 2:41 PM I like the idea to have a slave replicated node to make the backup 2:41 So it would not interfere with the master's one 2:42 Maybe we can fire it up then destroy it 2:42 I'm not sure Nikhil 2:43 PM Yeah. Let's do some more research and discuss more strategies over this week. Michaël Ohayon 2:43 PM Yes we have some time to think about that :smile: 2:45 I guess I have nothing more to add for now 2:45 :slightly_smiling_face: 2:45 Do you have any question or is everything clear on how to progress? Nikhil 2:46 PM So the tasks for this week can be: Update nodejs-helm and give it a feature to add --all-namespaces in its api calls. Install the Helm charts using SSP in the default namespace. Research about the backup and restore strategies for the mongodb-replicaset. Finalise the SSP Chart beta, add a documentation and add it on github. :+1: 1 2:46 Do you have any question or is everything clear on how to progress? Yeah, the tasks for this week are clear. 2:47 I need to add kubectl exec command permission to the SSP deployment. I have not tested that yet. (edited) 2:48 We need that to create admin account using SSP. 2:49 Btw thanks a lot for helping out with that presence on port 8039 issue. That issue when added with https issue gave a hard time. Michaël Ohayon 2:49 PM :grin: You're welcome 2:50 That port thing is really tricky on Kubernetes things they really don't like us opening ports on others things than the default ones (edited) Nikhil 2:50 PM Yeah right Michaël Ohayon 2:50 PM It's good for standards but yes complicated for this usecase :+1: 1 Nikhil 2:51 PM This week I'll be packing and moving home. I think it won't affect this weeks' tasks. But it might in uncertain circumstances :sweat_smile:. But it'll be fine. Michaël Ohayon 2:51 PM Yeah no worries 2:51 Do what you need to be safe and ok first Nikhil 2:51 PM Okay! Thanks Michaël Ohayon 2:52 PM It's not like we were having some big delays issues Nikhil 2:53 PM Yeah. Looks like the project will be completed a lot earlier. It's already in the working stage. We just need to package it and add backup/restore service. 2:53 Maybe add tests later. 2:54 I'm not sure what we'll do during the last month of the coding period :joy: Michaël Ohayon 2:56 PM Do not worry we'll have fun looking at Azure or AWS :joy: 2:56 I'm sure they will be some fun issues Nikhil 2:56 PM Yeah 2:56 Should we end this meeting? Michaël Ohayon 2:58 PM Yes ! Nikhil 2:58 PM Have a nice day! Michaël Ohayon 2:58 PM :+1: good work as always :smile: 1
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
