News for hackers. Stuff that matters.
Re:Why we started CoreOS by cyphar on Monday September 18, 2017 @12:16AM (#15273366)
Big disclaimer, I work for SUSE on the team for this product (though I actually work on upstream projects more than the product itself).

SUSE's "Container as a Service Platform"[1] has a one-page install for each node with an admin panel that does auto-provisioning. It also has transactional updates and a few other nice features similar to CoreOS's "Container Linux". In addition, we're working on openSUSE Kubic[2] which will be the community-developed base for CaaSP in the future.

I believe most if not all of the code is available on GitHub[3] under a free software license (because that's how we do things). Not to mention that you could very easily fork openSUSE Kubic, once it's ready.

[1]: https://www.suse.com/communities/blog/introducing-suse-conta... [2]: https://news.opensuse.org/2017/05/29/introducing-kubic-proje... [3]: https://github.com/kubic-project

Re:Why we started CoreOS by rjzzleep on Monday September 18, 2017 @07:03AM (#15274798)
Given that you work for SUSE and I kinda like you guys, I really hope that it's different from SLES licensing model.

I work at a german govt. institution which uses SLES and we've recently decided to move away from SLES for a simple reason. If you want to use something like immutable infrastructure SLES is painful to use, because you need to do everything through the SMT admin.

You won't even know which packages are available in SLES until you signup for it. Sure you can use openSUSE, but it's not the same packages, it's not the same package versions, and the open repo, while nice, is imho not as comfortable to use as ubuntu packages. IMHO it's not very user friendly.

And yes yast2 is great, but I'm not talking about graphical user interfaces when I say user friendly.

By the way, there are a few more "ContainerOSs" than just CoreOS nowadays.

- There's project atomic [1] which became atomic host [2]

- There's RancherOS, which I find interesting because it seems to have first class zfs support [3]

[1]: http://www.projectatomic.io/docs/kubernetes/

[2]: https://www.redhat.com/en/resources/enterprise-linux-atomic-...

[3]: http://rancher.com/docs/os/v1.0/en/storage/using-zfs/

Re:Why we started CoreOS by cyphar on Monday September 18, 2017 @07:23AM (#15274882)
I'm not involved in sales, so I can't really comment on what the licensing model is like.

> If you want to use something like immutable infrastructure SLES is painful to use, because you need to do everything through the SMT admin.

CaaSP nodes don't really have configurable packages (though I think that's something we're considering adding in the future). Everything is done using Kubernetes specifications, so you won't need to use SUMA to manage your nodes' running containers (though the admin panel is fairly similar when bootstrapping and maintaining a cluster).

> Sure you can use openSUSE, but it's not the same packages, it's not the same package versions, and the open repo, while nice, is imho not as comfortable to use as ubuntu packages.

This is something we've changed quite recently. You can figure out the package versions through Leap (and the SLE sources are actually visible in OBS from memory). There's also a "SUSE PackageHub" which is basically openSUSE backports that don't invalidate your license but are not directly supported (other than the same support we'd give to openSUSE issues). I think this is something I should raise with Richard Brown though, since on paper you should already have this information from the verbatim SLE sources we release that Leap is based on.

> By the way, there are a few more "ContainerOSs" than just CoreOS nowadays.

Yeah, though I expected (and was right) that people who work on those would be more knowledgable than me to comment on them. I work quite a lot with both of those groups on upstream stuff, so I'm well aware that they exist (in fact I've contributed to several Project Atomic projects in order to be able to re-purpose their code and use it with our OCI tooling[1]).

[1]: https://github.com/openSUSE/umoci