Hi Imesh,
On Wed, Jun 8, 2016 at 5:32 AM, Imesh Gunaratne <[email protected]> wrote: > It would be better if we can implement this feature without tightly > coupling with the K8S API. Therefore I prefer the pull based model than > this. > I agree. This would require different ways of contacting any platform specific name resolution service to get the list of target containers. > > >> The pull method works the other way, i.e. initiated by the GW worker >> nodes and has to be run continuously on a loop. >> > > This approach can be applied to API-M on any container cluster manager > (and also on VMs) with very few changes. AFAIU it's matter of changing how > SSH server and rsync command processes are run on each GW node. K8S can use > separate containers for these using pods and Mesos can use supervisord [4]. > I think supervisord would be applicable to any Docker based platform, be it Kubernetes or Mesos. Is there an additional advantage in going for a separate container to run sshd with a shared volume? One complication we'll come across (regardless of whether rsync pull or push) that I couldn't further elaborate was the artifact synchronization *between* GW Manager nodes when manager is in HA. This is when there are multiple GW Manager nodes, fronted with a load balancer. There will be only one active pod at a given time, and the request will be directed to the next available pod when the former goes down. For this, if we use a hostPath approach to share data, we'll also need to specify a node affinity to limit the node that the pod is spawned on. This way we can make sure the same location is mounted to every pod. The other option is to use something like Flocker with a Block storage service, however IMO it is a too complex method to approach a simple problem. Regards, Chamila de Alwis Committer and PMC Member - Apache Stratos Software Engineer | WSO2 | +94772207163 Blog: code.chamiladealwis.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
