Hello. On 09/14/2018 09:48 AM, Carsten Haitzler (The Rasterman) wrote: > On Wed, 12 Sep 2018 12:44:52 +0200 Stefan Schmidt <[email protected]> > said: >> 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.
As I am not going to handle anything of this my opinion on it is not worth much. I find containers easy to use for such things. What I really want to see in the end so is a system where we have a _group_ of people having access and understanding the system. >> 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. I guess you should ask Beber how to get access to IPMI (password, etc) and if he fails to reply you would need to go back to OSUOL. They should still have you listed as a person with rights to access, I hope (?). >> 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. :( Not much difference from the dark place we are in right now with our own infrastructure. :( > 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. This is something I do not agree with. I have been kicking into pants for problems with the infra for _years_ when doing Jenkins. It has changed nothing and I moved over to cloud services to get the control and flexibility I needed. Making a fixed infra a dependency for the potential move to gitlab is not reasonable in my opinion. Forcing it to wait on something that has not happened in 15 months and putting the extra work on the shoulders on people who want to handle the move. Its like telling someone who wants to add a new elm widgets to finish interfaces and get it out of beta first. :-) The infra problem should get tackled and if enough people are supporting a move to gitlab and doing the work it would be fair to let them to this in parallel. regards Stefan Schmidt _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
