3 ms·

As someone who runs OpenStack clusters and uses public cloud providers, I think it's worth noting a few things: - Outside of the Telco sector, OpenStack is bas

As someone who runs OpenStack clusters and uses public cloud providers, I think it's worth noting a few things: - Outside of the Telco sector, OpenStack is basically dead. - Even within Telco, everyone sees the writing on the wall of OS being dead and is looking to make the jump. - OpenStack is a cluster of poorly-interoperating, poorly-documented products -- The customer experience is fucking terrible. - DO, Hetzner, etc all offer a superior product. - None of those products even come close to touching the features of the big three clouds or even Oracle. If your needs could be well-served by DO, Hetzner, etc., then your needs could be well served by racks in a colo. Past that scale, American cloud providers are really your only option if you want that level of automation. (Or Chinese cloud providers, but largely assuming that's a non-option)

0xbadcafebee 2y ago
Well as someone who's actually used them as a customer, OpenStack hosting providers do give more functionality than DO, Hetzner, etc, plus they have an open API. None of them compete with the "big 4" public clouds (everyone forgets Oracle is still around...) but if all you want is IaaS then you don't need them. I know OpenStack is a tire fire to maintain, I've worked with it for large-scale on-prem data solutions. But if a company wants to kill themselves to maintain it for me, I'm happy to pay for the privilege.
- busterarm 2y ago
  Being a customer of an OpenStack provider isn't exactly a picnic. I could show you a long stack of support tickets from all of the things constantly going wrong.
  - evolve2k 2y ago
    Given a long list of support tickets vs Effectively relying on responsible stewardship by Musk and the King of America, I suspect there will be many a developer who find the long list of ticketed issues to be the less hard problem to tackle.
    - busterarm 2y ago
      There are sadly a lot of "sky is falling" type people out there yes. This is why we have to determine a threat model before we implement a security response... But that's also the point of my other comment in the thread -- a French company builds basically all of the physical infrastructure that datacenters run on. This attitude can be applied both ways.
nyrikki 2y ago
> OpenStack is a cluster of poorly-interoperating, poorly-documented products -- The customer experience is fucking terrible. I assume you were unfortunately a victim of Mirantis/Fuel/Puppet/Mcollective... or one of the 'converged' solutions. While I wouldn't call OpenStack "fun" Especially in the Essex to Icehouse era, where vendors seriously impacted the code stability...It is just a well documented collection of separate components that interact using REST api's and RPC like calls over a message bus. Nvidia, Cern, JPL, and lots of smaller companies that need private clouds and have the expertise are still running OpenStack. For me the main value is the ability to have portability between public and private. If you just use the ansible playbooks included in every OS repo, it is pretty easy to roll your own deployments that are quite easy to maintain if and only if your company is mature enough to follow that model and isn't subject to the soicotechnical issues that plague containers too. While the workflow changes, the hard parts of OS and k8s, including networking, monitoring, etc,.. are exactly the same. As a random example of what always screws this up let me point at kubespray, which is not unique at all. Note the: > Remove docker requirements https://github.com/kubernetes-sigs/kubespray/issues/6400 https://github.com/kubernetes-sigs/kubespray/issues/6400 That is because, like many projects, they didn't respect the natural boundaries of the node components, and they are now paying the price for that debt. k8s and OS from an infrastructure point of view are equal in complexity. It isn't instantiating a container with CRI foo, or libvirt command bar that is the hard part. It is the distributed computing, virtual networking , resource allocation, federation, API's etc... that is hard. Note, if you think that the "OS is dead" for all needs, especially in the telco space, you may want to dig into what containers actually are. They are just namespaces running on an OS, and it will still be horses for corses as to what is appropriate. Especially if you are using the easy ways of instantiating hardware for k8s, almost all of them are highly insecure by default and you are going to have to dig into the same style of systems with similar components or you will have a leak of data at some point. I wish there was something better than OS, but if you use a dev mindset and not a glass house IT mindset it is a very useful tool that may be the least worst option for you for some needs.
- busterarm 2y ago
  No and No. It's not about the complexity of it or being any worse/better than K8s. It's about the endless bugs and regressions and laundry list of stupid problems caused by inadequate processes by OpenStack developers. For example, let's say you're running Cinder v3. Cinder 3.59. You want to get the volumes that you have attached to an instance, so you curl the API: /cinder/v3/<instance id>/attachments. You get a 404. You get a 404 because you didn't pass this header: "OpenStack-API-Version: volume 3.27". Because Cinder defaults to Cinder 3.01 behavior even when you're running 3.59. Attachments were only added in 3.27. So even though you're trying to curl a route that wouldn't even exist in 3.01 and you're running a version clearly later than 3.27, the API responds as if it's Cinder 3.01 unless you specifically tell it to do otherwise. And this is just one of the laundry list of stupid situations that I can remember off the top of my head. When the thing isn't otherwise failing all the time.

0xbadcafebee 2y ago

Well as someone who's actually used them as a customer, OpenStack hosting providers do give more functionality than DO, Hetzner, etc, plus they have an open API. None of them compete with the "big 4" public clouds (everyone forgets Oracle is still around...) but if all you want is IaaS then you don't need them. I know OpenStack is a tire fire to maintain, I've worked with it for large-scale on-prem data solutions. But if a company wants to kill themselves to maintain it for me, I'm happy to pay for the privilege.

busterarm 2y ago
Being a customer of an OpenStack provider isn't exactly a picnic. I could show you a long stack of support tickets from all of the things constantly going wrong.
- evolve2k 2y ago
  Given a long list of support tickets vs Effectively relying on responsible stewardship by Musk and the King of America, I suspect there will be many a developer who find the long list of ticketed issues to be the less hard problem to tackle.
  - busterarm 2y ago
    There are sadly a lot of "sky is falling" type people out there yes. This is why we have to determine a threat model before we implement a security response... But that's also the point of my other comment in the thread -- a French company builds basically all of the physical infrastructure that datacenters run on. This attitude can be applied both ways.

nyrikki 2y ago

> OpenStack is a cluster of poorly-interoperating, poorly-documented products -- The customer experience is fucking terrible. I assume you were unfortunately a victim of Mirantis/Fuel/Puppet/Mcollective... or one of the 'converged' solutions. While I wouldn't call OpenStack "fun" Especially in the Essex to Icehouse era, where vendors seriously impacted the code stability...It is just a well documented collection of separate components that interact using REST api's and RPC like calls over a message bus. Nvidia, Cern, JPL, and lots of smaller companies that need private clouds and have the expertise are still running OpenStack. For me the main value is the ability to have portability between public and private. If you just use the ansible playbooks included in every OS repo, it is pretty easy to roll your own deployments that are quite easy to maintain if and only if your company is mature enough to follow that model and isn't subject to the soicotechnical issues that plague containers too. While the workflow changes, the hard parts of OS and k8s, including networking, monitoring, etc,.. are exactly the same. As a random example of what always screws this up let me point at kubespray, which is not unique at all. Note the: > Remove docker requirements https://github.com/kubernetes-sigs/kubespray/issues/6400 https://github.com/kubernetes-sigs/kubespray/issues/6400 That is because, like many projects, they didn't respect the natural boundaries of the node components, and they are now paying the price for that debt. k8s and OS from an infrastructure point of view are equal in complexity. It isn't instantiating a container with CRI foo, or libvirt command bar that is the hard part. It is the distributed computing, virtual networking , resource allocation, federation, API's etc... that is hard. Note, if you think that the "OS is dead" for all needs, especially in the telco space, you may want to dig into what containers actually are. They are just namespaces running on an OS, and it will still be horses for corses as to what is appropriate. Especially if you are using the easy ways of instantiating hardware for k8s, almost all of them are highly insecure by default and you are going to have to dig into the same style of systems with similar components or you will have a leak of data at some point. I wish there was something better than OS, but if you use a dev mindset and not a glass house IT mindset it is a very useful tool that may be the least worst option for you for some needs.

busterarm 2y ago
No and No. It's not about the complexity of it or being any worse/better than K8s. It's about the endless bugs and regressions and laundry list of stupid problems caused by inadequate processes by OpenStack developers. For example, let's say you're running Cinder v3. Cinder 3.59. You want to get the volumes that you have attached to an instance, so you curl the API: /cinder/v3/<instance id>/attachments. You get a 404. You get a 404 because you didn't pass this header: "OpenStack-API-Version: volume 3.27". Because Cinder defaults to Cinder 3.01 behavior even when you're running 3.59. Attachments were only added in 3.27. So even though you're trying to curl a route that wouldn't even exist in 3.01 and you're running a version clearly later than 3.27, the API responds as if it's Cinder 3.01 unless you specifically tell it to do otherwise. And this is just one of the laundry list of stupid situations that I can remember off the top of my head. When the thing isn't otherwise failing all the time.