At the moment, we allow multiple users to access the same CoreOS cluster by handing out double-digit ID numbers to keep their services and ports from colliding. This is manual, annoying, and it doesn't scale well. We need a better solution.
When dealing with CoreOS services, we are limited by non-dynamic nature of the unit-files. Dan and I both wrestled with them looking for a solution within the framework of systemd. The result was the oddly cumbersome scheme mentioned above.
I think the best solution is to not rely on systemd. We don't really care what ports or service names get assigned so long as they don't collide. Since this is a relatively low-bar, I think it would be reasonable to create a (very simple) tool that uses your SSH access to the cluster to interface with etcd and fleetctl.
We can store port assignments in etcd. That way, every time we come across a port we assign port n+1, where n is the last assigned port. I recommend using #{port} as a placeholder inside the .service files. Our tool can target that tag and replace them appropriately.
For the name of service files, we could either count services that returned from the "list-units" command or we can just assign random hashes that are unlikely to collide.
I am a little concerned that this plan lacks the elegance I want to feel from a final solution. But it is very direct. How comfortable would you be with that kind of solution?
At the moment, we allow multiple users to access the same CoreOS cluster by handing out double-digit ID numbers to keep their services and ports from colliding. This is manual, annoying, and it doesn't scale well. We need a better solution.
When dealing with CoreOS services, we are limited by non-dynamic nature of the unit-files. Dan and I both wrestled with them looking for a solution within the framework of systemd. The result was the oddly cumbersome scheme mentioned above.
I think the best solution is to not rely on systemd. We don't really care what ports or service names get assigned so long as they don't collide. Since this is a relatively low-bar, I think it would be reasonable to create a (very simple) tool that uses your SSH access to the cluster to interface with etcd and fleetctl.
We can store port assignments in etcd. That way, every time we come across a port we assign port n+1, where n is the last assigned port. I recommend using #{port} as a placeholder inside the .service files. Our tool can target that tag and replace them appropriately.
For the name of service files, we could either count services that returned from the "list-units" command or we can just assign random hashes that are unlikely to collide.
I am a little concerned that this plan lacks the elegance I want to feel from a final solution. But it is very direct. How comfortable would you be with that kind of solution?