11 ms·

Scaleway customer here. I read a review on HN a while back that got me to buy into their service. While on the surface, it seems like a great value, there are i

Scaleway customer here. I read a review on HN a while back that got me to buy into their service. While on the surface, it seems like a great value, there are inconsistencies I cannot reconcile that have kept me on DigitalOcean and GCP since. For example, there's quite a bit of funny business going on in all of their stock kernels, so much so that you can't even run things like Docker or Minikube. If you try and install your own kernel mods, you'll find that an uphill battle as well.

drdaeman 10y ago
I run a C1 instance with Docker, and there weren't any immediate issues with stock kernels for me (I think I've switched between at least 4-5 during the year). Except when a systemd upgrade broke things and I had to reconnect the drive, but that wasn't Docker-related. However, I haven't had anything fancy there. (Docker multiarch support - or better say lack of one - is still a complete mess though. But that's also not a Scaleway issue.) There are tricks to running your own kernel there (via kexec), for Arch it's neatly packaged here: https://github.com/stuffo/scaleway-archkernel https://github.com/stuffo/scaleway-archkernel (but new servers don't have Arch as an option) Still, it's all terribly inconvenient. Possibly fun to mess with once, DIY/learning-style... but if you just want a server that works (and works in a way you want things to be, not how vendor had set it up) it could be sort of unpleasant.
- jameskegel 10y ago
  It's very unpleasant considering half of their github scripts, including the one you listed, in my experience just flat out don't run how they were intended anymore.
ch0wn 10y ago
I've never had issues running docker on their instances. Was that on ARM or x86? I've only used the latter so far.
user5994461 10y ago
Mandatory read: https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.com/2016/11/01/docker-in-production-an-his... https://thehftguy.com/2017/02/23/docker-in-production-an-update/ https://thehftguy.com/2017/02/23/docker-in-production-an-upd... If you have issue with Kernels and Docker. It's not just you and it's not entirely the fault of the provider. ;)
- ryukafalz 10y ago
  He has some good points, but... >All CI pipelines in the world which rely on docker setup/update or a system setup/update are broken. It is impossible to run a system update or upgrade on an existing system. It’s impossible to create a new system and install docker on it. If the loss of package repos counts as a critical outage for you, you should be running your own package mirrors. Especially if you're not paying for commercial support and don't have anyone to escalate issues to.
  - user5994461 10y ago
    The package repo is not lost. It is online and serving packages with corrupted signatures. That's a crypto error interpretable as an active MITM attack on the repo, which causes a apt-get and subcommands to terminate abruptly with a critical error. Last but not least, the repository is mirrored and cached, the mirrors simply reproduced the corrupted source repo :D It is not a mere case of offline repository, though I can understand the confusion ;)
    - ryukafalz 10y ago
      I'm well aware of how traditional "dumb" mirrors work (e.g. ftpsync), and those would indeed just mirror the packages with their incorrect signatures. But for an internal network, surely you'd want something more like aptly[0] so you can roll back to a working version? [0] https://www.aptly.info/doc/overview/ https://www.aptly.info/doc/overview/
      - 10y ago
pstadler 10y ago
I'm running a fully functional Kubernetes cluster on VC1S servers (x86) using this guide[1]. In case you're stuck compiling Kernel modules or running Docker, check out how it's done in the provisioner[2] that comes with the guide. [1] https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide [2] https://github.com/hobby-kube/provisioning https://github.com/hobby-kube/provisioning Disclaimer: I'm the author of this project

drdaeman 10y ago

I run a C1 instance with Docker, and there weren't any immediate issues with stock kernels for me (I think I've switched between at least 4-5 during the year). Except when a systemd upgrade broke things and I had to reconnect the drive, but that wasn't Docker-related. However, I haven't had anything fancy there. (Docker multiarch support - or better say lack of one - is still a complete mess though. But that's also not a Scaleway issue.) There are tricks to running your own kernel there (via kexec), for Arch it's neatly packaged here: https://github.com/stuffo/scaleway-archkernel https://github.com/stuffo/scaleway-archkernel (but new servers don't have Arch as an option) Still, it's all terribly inconvenient. Possibly fun to mess with once, DIY/learning-style... but if you just want a server that works (and works in a way you want things to be, not how vendor had set it up) it could be sort of unpleasant.

jameskegel 10y ago
It's very unpleasant considering half of their github scripts, including the one you listed, in my experience just flat out don't run how they were intended anymore.

ch0wn 10y ago

I've never had issues running docker on their instances. Was that on ARM or x86? I've only used the latter so far.

user5994461 10y ago

Mandatory read: https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.com/2016/11/01/docker-in-production-an-his... https://thehftguy.com/2017/02/23/docker-in-production-an-update/ https://thehftguy.com/2017/02/23/docker-in-production-an-upd... If you have issue with Kernels and Docker. It's not just you and it's not entirely the fault of the provider. ;)

ryukafalz 10y ago
He has some good points, but... >All CI pipelines in the world which rely on docker setup/update or a system setup/update are broken. It is impossible to run a system update or upgrade on an existing system. It’s impossible to create a new system and install docker on it. If the loss of package repos counts as a critical outage for you, you should be running your own package mirrors. Especially if you're not paying for commercial support and don't have anyone to escalate issues to.
- user5994461 10y ago
  The package repo is not lost. It is online and serving packages with corrupted signatures. That's a crypto error interpretable as an active MITM attack on the repo, which causes a apt-get and subcommands to terminate abruptly with a critical error. Last but not least, the repository is mirrored and cached, the mirrors simply reproduced the corrupted source repo :D It is not a mere case of offline repository, though I can understand the confusion ;)
  - ryukafalz 10y ago
    I'm well aware of how traditional "dumb" mirrors work (e.g. ftpsync), and those would indeed just mirror the packages with their incorrect signatures. But for an internal network, surely you'd want something more like aptly[0] so you can roll back to a working version? [0] https://www.aptly.info/doc/overview/ https://www.aptly.info/doc/overview/
    - 10y ago

pstadler 10y ago

I'm running a fully functional Kubernetes cluster on VC1S servers (x86) using this guide[1]. In case you're stuck compiling Kernel modules or running Docker, check out how it's done in the provisioner[2] that comes with the guide. [1] https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide [2] https://github.com/hobby-kube/provisioning https://github.com/hobby-kube/provisioning Disclaimer: I'm the author of this project