applications issueshttps://forge.liiib.re/indiehost/applications/-/issues2015-05-02T19:56:40Zhttps://forge.liiib.re/indiehost/applications/-/issues/26Rename the repo2015-05-02T19:56:40ZOzouxRename the repoI think a better name would be `michiel-app-store` or `michiel-implementation`. I'll have my own also, and then from October, we'll work on merging both. (it will be easier to do this AFK)
I think a better name would be `michiel-app-store` or `michiel-implementation`. I'll have my own also, and then from October, we'll work on merging both. (it will be easier to do this AFK)
https://forge.liiib.re/indiehost/applications/-/issues/24discussion about which meta-software to offer2015-05-02T20:01:39ZOzouxdiscussion about which meta-software to offer*Created by: michielbdejong*
I think it's quite clear we want to offer certain base functionality:
- identity: a domain name you control, with a (static) website served over https
- decentralized communication: email, jabber, pubsubhubb...*Created by: michielbdejong*
I think it's quite clear we want to offer certain base functionality:
- identity: a domain name you control, with a (static) website served over https
- decentralized communication: email, jabber, pubsubhubbub
- blogging: tools so that you can more easily publish content on the web
- file hosting: tools so that you can keep your photos and files on your server
And then there are miscellaneous apps that have some specific functionality, which are each sort of isolated and light-weight to add, like maybe:
- gitlab,
- etherpad,
- bugzilla,
- addressbook,
- calendar,
- etcetera.
but at another level, there is a number of important meta-software projects out there that we may just want to offer hosting for, without them being necessarily a miscellaneous app. Each of them covers basically file sharing + a lot of miscellaneous apps, and each user would need only one of those, because they replace each other. i think at the moment the most important ones in terms of momentum are (my knowledge may be incomplete here?):
- owncloud
- cozycloud
- sandstorm
- yunohost
- arkos
- turnkeylinux
i'm sure there will be others over the years. would it make sense to just try to offer hosting for each of these? i guess each have their pros and cons, and it's good if people can try them out, compare them, and use the best one for daily use on their domain name, hosted by their indiehoster.
https://forge.liiib.re/indiehost/applications/-/issues/21Discussion about infrastructure2014-09-01T10:14:10ZOzouxDiscussion about infrastructureAfter reading all:
http://www.slideshare.net/bobtfish/docker-confjune2014
http://nerds.airbnb.com/smartstack-service-discovery-cloud/
http://clockworkcubed.com/2014/05/consul-and-synapse-service-discovery-and-elastic-load-balancing/
http...After reading all:
http://www.slideshare.net/bobtfish/docker-confjune2014
http://nerds.airbnb.com/smartstack-service-discovery-cloud/
http://clockworkcubed.com/2014/05/consul-and-synapse-service-discovery-and-elastic-load-balancing/
http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/
http://jasonwilder.com/blog/2014/07/15/docker-service-discovery/
http://www.consul.io/intro/vs/smartstack.html
http://igor.moomers.org/smartstack-vs-consul/
I feel this is the path:
https://coreos.com/blog/docker-dynamic-ambassador-powered-by-etcd/
Ouh, I'm getting excited :)
So the idea would be to have a manifest file for each of app we support.
I will write a BDD scenario:
Given a user (john) wants to access his wordpress the first time
And the user has already an account with indiehosters
When he goes to his [app store page](http://libreprojects.net/)
And he clicks on wordpress
Then he is redirected to john.indiegue.st/wordpress
And our user sees a waiting page
Then our backend catches this http request
And our backend understands that there is no wordpress for this user
And our backend read the manifest file for wordpress
And our backend satisfies MySQl dependencie
(Given a user (john) wants to access his mysql the first time...)
And our backend satisfies all [dependencies](http://12factor.net/backing-services)
And our backend send the http request to the service ambassador
And the service ambassador responds
The idea is that I don't want poor failover made by hand. Technology is mature for kickass failover. I want to have a rocking service. When one of the VM is down, I don't want the service down for the user :) So yes, one MySQL per user, but a replicated master-master one! And every services consuming MySQL are able to do it so, even if one MySQL instance is down :)
I'm still hoping that we don't have to write this manifest file, and could handle it at the Fleet or Docker level.
And about some services that are shared among users (mail, jabber..), I strongly believe we should use the same scemas as for users. We should dog food it ;) It's not a special case, it's just that the user is Michiel instead of John ;)
And I don't think we will run backup of services of each others (cross hosters). I will personaly have 3 VMs, and they'll backup each other. It's either that, or we share a common cluster (3 VMs also, but we can grow them to more).