<rekado>I think page 35 (4.3.1. Translation as a central feature of Charite) matches what I’ve been observing
<rekado>it’s like the ultimate win for the basic research institutes is to spin off a startup or a product that gets used in a clinical context, e.g. at Charite.
<rekado>“Development of new forms of interaction with partner organizations, start-ups and spin-offs”
<rekado>do any of you have practical experience with OpenStack?
<rekado>we’d like to start playing with OpenStack, primarily as a go-between from traditional HPC to AWS. I’d think that we could prevent all of HPC from moving to AWS (due to perverse cost incentives once you start using AWS) by having a “local cloud”.
<rekado>I’m looking for arguments for setting up OpenStack without making people think it’s meant to be a competitor to our HPC cluster.
<zimoun>Maybe you can reach out Pierre-Antoine from GriCAD, I think they are using OpenStack there. Or maybe Yann from CCIPL.
<civodul>rekado: OpenStack is terrrrrible, tells me a friend who's been working on it for Red Hat for several years
<civodul>terrible in the sense that it's a huge bloated thing
<rekado>one thing that appeals to me is that they have an EC2-compatible API
<rekado>so going from AWS to local OpenStack would seem like a possibility
<rekado>(and the other way around, which is a selling point for those who’d rather have us ditch HPC and move everything to AWS)
<civodul>rekado: i don't really know tools in this space
<civodul>i don't really relate to the needs i guess
<rekado>it’s a bit of an odd in-between space that’s ripe with marketing speak and ill-defined needs
<rekado>we currently set up custom VMs for users whenever they want to build a service
<rekado>since it’s not possible (for users) to define infrastructure with software (and on demand) they usually never go beyond their VM
<rekado>the VM is usually mismatched to the requirements, because it doesn’t scale up or down
<rekado>so we end up with 50 or so custom VMs that are all little pets.
<rekado>hard to maintain responsibly, unable to scale, and with the expectation that users take care of the VM even though they really only care about their application.
<rekado>the marching direction is of course set by those who envy “cloud-first pioneers” like the Broad Institute, and assume that using AWS “somehow” would cut out IT and thus free them from admins saying “no”.
<rekado>so there’s this vague “we must do something with the cloud” combined with our inability to provide a flexible solution for those where neither HPC nor custom VM is the right answer.
<zimoun>«using AWS “somehow” would cut out IT and thus free them from admins saying “no”», bah “somehow”, there is no free lunch. ;-)
<civodul>rekado: in the sense that OpenStack is now much more popular than CloudStack, AIUI
<civodul>(and popularity is everything, isn't it?)
<rekado>yeah, there’s a mental shortcut they take. I think that’s inspired by their dislike for IT in general.
<rekado>civodul: oh, see: I read CloudStack as OpenStack. “cloud” and “open” are such empty non-words that they don’t even register for me :)
<rekado>I’m pretty annoyed by these *huge* software stacks. I’m not saying they’re “doing it wrong”, but it seems like a *lot* of software for a pretty limited feature set.
<rekado>I’d like to have an API thing (ideally one that looks like AWS, because then I don’t need to write new code) that I can use to spawn VMs, configure networking between them, and move around workloads.
<rekado>but all these “solutions” are way more than just that API implementation
<rekado>they are web interfaces, storage management thing, …
<zimoun>Parisian hospitals invested in “cloud“ with a team of 6+ skilled people. They built a really good solution (Debian, Docker, frontend, etc.). It works well, from what I am seeing. Some MDs are still wanting to go to AWS because Broad Institute and they think it will be better by cutting stuff. Field is always more green for the neighbour (french proverb :-)).
<rekado>‘the grass is always greener on the other side’
<rekado>bioinfo/med people looking at Broad Institute for best practices is like web startups copying what Google does.
<mbakke>civodul: Kubernetes has a declarative deployment API, where you can describe complete services in terms of "pods" (one or more instances of the same container image), along with HTTP routes (/ to this pod, /archive to that pod), persistent storage for some pods, etc.