2020-11-01T03:13:51  *** okurz_ is now known as okurz
2020-11-01T15:19:27  <Eighth_Doctor> LCP: what do you mean we don't have a setup for Uyuni?
2020-11-01T15:19:48  <Eighth_Doctor> you mean that lists.uyuni-project.org doesn't have MX records and such?
2020-11-01T16:10:38  <lcp> it does, our mx doesn't direct those emails to mailman machine
2020-11-01T19:39:13  <bmwiedemann1> Eighth_Doctor / lcp / cboltz : there were thoughts about moving parts of openSUSE infra into a cloud. What services do you think, are most cloud-ready - e.g stateless or fully in salt. I was thinking static.o.o was a good candidate.
2020-11-01T19:39:47  <Eighth_Doctor> pretty much all the services LCP and I have been working on would work well there
2020-11-01T19:39:59  <Eighth_Doctor> since we're doing it fully in salt and have some degree of scaling plans
2020-11-01T19:40:34  <cboltz> to be honest, I'm not a fan of moving things to the cloud
2020-11-01T19:40:40  <Eighth_Doctor> depends on the cloud service and features we'd use though
2020-11-01T19:41:03  <bmwiedemann1> a cloud is just someone else's computers.
2020-11-01T19:41:26  <cboltz> I know ;-)
2020-11-01T19:41:43  <cboltz> just wondering - where do these thoughts come from?
2020-11-01T19:43:56  <bmwiedemann1> one: it could allow for some agility - e.g. heroes being able to see VM consoles and maybe launch/scale VMs
2020-11-01T19:44:55  <bmwiedemann1> some people probably also think that operating a datacenter is not core business for SUSE
2020-11-01T19:45:41  <cboltz> maybe, but I doubt that for example OBS will be moved to a cloud (I'd guess it's too expensive), so SUSE will keep the datacenter anyway ;-)
2020-11-01T19:46:09  <bmwiedemann1> it could also increase reliability - being less affected by power or network outages
2020-11-01T19:47:15  <bmwiedemann1> yes, some parts indeed have to stay.
2020-11-01T19:55:26  <bmwiedemann1> cboltz: what would be your concerns?
2020-11-01T19:56:35  <cboltz> not sure if "concerns" is the right word ;-)
2020-11-01T19:57:16  <cboltz> 1 - we have some "experience" with MF-IT, and if any outsourcing or cloud is only half as bad as they were, it would still be bad
2020-11-01T19:57:35  <cboltz> OTOH, the experience within the SUSE datacenter and heroes network is quite good
2020-11-01T19:58:13  <cboltz> 2 - I never used that cloud stuff, so I'd start as a complete newbie ;-)
2020-11-01T19:59:48  <bmwiedemann1> I dont think it will be anything like MF-IT. It is supposed to all be self-service via APIs or a Web-frontend and the worst that should happen is insufficient performance
2020-11-01T20:02:01  <bmwiedemann1> in principle, cloud credentials could leak and someone could delete all VMs and replace them with crypto-miners.
2020-11-01T20:03:54  <cboltz> I think I've read such stories - but at least in the case I remember, the attacker "only" added VMs for crypto-mining which made the attack expensive, but not a whole desaster ;-)
2020-11-01T20:05:01  <bmwiedemann1> cboltz: you probably know 'virsh' to manage VMs. clouds are similar - only that you do not get told on which host VMs run.
2020-11-01T20:05:49  <bmwiedemann1> and sometimes VM sizes use presets for combinations of CPU+RAM+Disk
2020-11-01T20:05:54  <cboltz> I have to admit that I always use virt-manager for my test VMs ;-) but I get your point
2020-11-01T20:06:25  <lcp> if you ask me, I would say mirrors would be useful in the cloud, to have at least something that may help us in the regions where we don't have good enough coverage yet
2020-11-01T20:07:21  <bmwiedemann1> lcp: for download infrastructure, I was thinking that caching proxies would be more useful, because they do not use bandwidth for all the write-only-data
2020-11-01T20:08:59  <bmwiedemann1> to users they would look like full mirrors, but cache misses would fall back to the main server
2020-11-01T20:10:45  <cboltz> sounds somewhat similar to mirrorbrain - if a mirror doesn't have a file, you don't get redirected to it and (in worst case) get it served from the main server
2020-11-01T20:11:16  <cboltz> so what's the advantage, and how would these caching proxies look to mirrorbrain?
2020-11-01T20:12:37  <lcp> bmwiedemann1: that does indeed make sense
2020-11-01T20:14:00  <bmwiedemann1> cboltz: the difference is that not every TW user goes to downloadcontent.o.o for files, but the caches deliver it on 2nd request
2020-11-01T20:14:43  <cboltz> ok, I get that part
2020-11-01T20:14:57  <bmwiedemann1> currently we delay TW releases by some hours to ensure enough mirrors are synced
2020-11-01T20:15:16  <cboltz> but - how would the mirrorbrain scanner see that cache? and why would mirrorbrain redirect to it if the file doesn't exist there yet?
2020-11-01T20:15:33  <cboltz> or do you think we should put such a caching proxy in front of download.o.o?
2020-11-01T20:15:56  <bmwiedemann1> cboltz: mirrorbrain could just assume that all files can be served by those caches
2020-11-01T20:16:34  <cboltz> indeed, that sounds like a doable solution
2020-11-01T20:16:52  <bmwiedemann1> it would relieve downloadcontent.o.o
2020-11-01T20:18:03  <bmwiedemann1> in theory, we could provide geo-ip/dns mirrors, e.g. us.download.o.o
2020-11-01T20:21:19  <cboltz> ah, thinking of the caches as sitting in front of downloadcontent (even if this description is technically not correct) makes more sense
2020-11-01T23:12:11  <malcolmlewis>  do the changes to the heroes ML go to heroes+subscribe-nomail@opensuse.org or heroes+subscribe-nomail@lists.opensuse.org