I can sponsor a Linode vps for this until we get the server back in shape Sent from my iPhone
> On 14 Sep 2018, at 09:48, Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > On Wed, 12 Sep 2018 12:44:52 +0200 Stefan Schmidt <ste...@datenfreihafen.org> > said: > >> Hello. >> >>> On 09/12/2018 10:24 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Thu, 30 Aug 2018 19:49:29 +0930 Simon Lees <sfl...@suse.de> said: >>> >>>> >>>> >>>>> On 30/08/2018 18:57, Stefan Schmidt wrote: >>>>> Hello. >>>>> >>>>>> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: >>>>>> >>>>>> Q: Where would this be hosted? >>>>>> A: The provided link here is a cloud service which will be funded for the >>>>>> foreseeable future. >>>>> >>>>> This is a crucial point here. Business decisions change and the >>>>> community has no influence on this. With my community hat on I >>>>> appreciate that there would be a sponsoring of a cloud service, but I >>>>> truly think we should not depend on this mid or long term (having it run >>>>> there for a few month of migration would not worry me). >>>>> Even if it would be more paperwork having the sponsorship going to the >>>>> foundation and the service being paid out from there would be the right >>>>> way. We can acknowledge the sponsorship on our sponsors page. >>>>> >>>> >>>> I tend to agree here, unless we knew we had a simple easy way to migrate >>>> it to other hosting at anytime we needed. >> >> If we would have, say a docker hosting it could start there and be >> migrated over to our own hosting whenever we get that into shape. >> Not saying its the best solution but it could be an option. > > containers are nicer but they do then create more of a limit of where we can > run. > >>> My experience leads me to be pretty adamant on not relying on cloud >>> services we have to pay for eve if someone sponsors and pays for it. We >>> lose control and reality is that these helping hands come and go. >> >> Using them for a given timeframe until we have our infra in better shape >> would make the risk manageable for them in terms of how much they >> sponsor and for us in terms of getting full control in the end. >> >> OSUOSL is a university and >>> they have been supporting OSS projects for a veeeeeery long time. We need to >>> get our server into better shape though. Probably simpler shape. >> >> This is the core problem. OSUOL has indeed doing a great job for us over >> the years for hosting and connectivity. But they can only be as good as >> we allow them to be. Waiting for us for a fan to be shipped to be >> replaced for over 6 months is nothing we are helping them with. >> >> To be blunt here our infra is a nightmare. To complex to manage for >> anyone besides Beber. Beber not being available means _nothing_ changes. > > precisely. I would like to go back to something very simple. not a bunch of > vm's or containers etc. ... my thoughts right now are a simple single sub vm > on > our current gentoo parent box. no fancy network layering/routing etc. ... then > it's manageable for multiple people as it's simple and obvious and easy to > figure out. yes. it's probably not as secure... but that's what the vm is for. > extract the data out, and rebuild if the worst happens. > > or at least something like the above. something very simple to manage/set > up/run etc. > >> Is that was all discussed during EDD in Malta in 2017 and promised to be >> worked on. This was 15 months ago and I see zero impact so far. >> >> This is not about to point fingers to Beber. He has been helping us many >> many years as a volunteer. He has all rights to take time off or even >> disappear completely and we still should be thankful for the work he did. >> >> It is however a big problem in the project if we want to self host >> everything, but our infra is simply not ready for it. > > well one big big big issue is the ipmi console. i have tried to get access to > it. i have asked cedric and beber. without that there is no way i can do a > kernel upgrade on a gentoo host because you have to compile by hand and > something is bound to go wrong... and without that console there is no rescue. > >> To summarize: I share your concerns on cloud hosting with sponsoring, >> but our infra is not ready for anything new. _If_ we move to gitlab >> having it hosted for a few months on a cloud service with a migration >> plan to our own infra is something I consider a fair deal. > > my gut and experience tells em few months then becomes a few years and then > something goes wrong and we're in a dark place. :( > > my take is that if there is to be any move in addition to it "being worth it" > we have to get our infra into shape FIRST. let this be the kick in the pants > to > do that. if we just put that off then it will just never happen as above. > >> regards >> Stefan Schmidt >> >> >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
