What are /r/coreos' favorite Products & Services?

From 3.5 billion Reddit comments

CoreOS shouldn't run in the containers. The way we did it was to have one VM running CoreOS and then the containers running in that VM. We used https://coreos.com/docs/running-coreos/platforms/vagrant/ and ran a single node cluster for the development environment. If you are talking about a production environment then CoreOS would be the host OS and the containers running on it.

For us each docker image was based on the appropriate base image for the process that was running.

If it helps, Matchbox is an example of booting CoreOS on PXE. https://coreos.com/matchbox/docs/latest/matchbox.html

I work at CoreOS, but I'm not sure about your particular error. I can recommend cross-posting this to https://github.com/coreos/bugs/issues/new

Devs read issues, and are the folks best equipped to help you troubleshoot. Be sure to include relevant debugging info! <3

It's literally in the patch notes, dude. No need to read any irc, mailing list, slacks etc. Just the notes. No need to be 100% on top of all the changes, only when you want to apply a change.

If you want to upgrade or install a new version, read the notes of all the versions in between if you're skipping a few. It took 2 minutes to find these.

https://coreos.com/releases/#1675.0.1

CloudConfig is a file format used by CoreOS. Nothing is stored in the cloud, the cloud-config is just a file that is provided to the operating system on boot.

https://coreos.com/os/docs/latest/cloud-config.html

Can you give examples of specifically what documentation you're having difficulties with?

In your title you seem to be referring to the public discovery service. There's guides on how to use an existing etcd cluster for discovery here: https://coreos.com/etcd/docs/latest/clustering.html#etcd-discovery

Bare metal docs are fairly brief, it's mostly on using coreos-install onto a disk or using PXE, but that's because those are really the only options. What else would you like to see? Anything in particular?

On the retirement notice page for CoreOS there's a link to the firm that will keep CoreOS going, albeit in a different name. On my phone and can't remember what it is, but it's easy to find.

Does anyone know if this Fedora CoreOS is the fabled "stream" Fedora rolling distribution that was extensively written about then disappeared?

Update: https://coreos.com/os/eol/ about half way down; flatcar.

It's sad that the Fedora Atomic project failed so they bought the competition and killed it, in a Microsoft like way. But as they say "no-one ever got fired for buying IBM".

"etcd v2 will no longer be shipped with Container Linux after June 2018. For information on working with previous versions, please see the etcd 2.3.7 Documentation."

https://coreos.com/etcd/docs/latest/

I am glad to see that it has been removed in April ...

You're largely looking at x86_64. If you're more risk tolerant, there are also a few options for building to other targets https://coreos.com/os/docs/latest/sdk-modifying-coreos.html

If it's a few thousand devices, I suggest posting on the user forums, and a dev can get a bit more technical with ya on the pros/cons of diff options. For instance, it's probably going to make your team feel more at ease to learn more about how Container Linux is tested every release.

https://groups.google.com/forum/#!forum/coreos-user

Brandon responded to a similar complaint on Twitter. https://twitter.com/BrandonPhilips/status/981939337725075457

> I am sorry for the trouble. This was an effort to remove deprecated software from early on in etcd's history. You can read more from the deprecation post in January 2017: https://coreos.com/blog/toward-etcd-v3-in-container-linux.html How could we have given you a better notification?

I work at CoreOS. If you have a suggestion for a better way to notify you, I'll make sure he sees it.

Good Q! This doc on mounting storage might answer part of your question.

As for whether your particular hardware is supported, best way to find out is to just test it.

Kubernetes has it's own way of dealing with this i believe, but if you were using fleet you'd use a sidekick container. The sidekick is automatically created on the same host when it creates the app container and is responsible for telling something else(load balancer, reverse proxy, etc) where it is and how to connect to it. fleet also cleans up a sidekick when its main container goes away.

Are you looking for something like flannel? https://coreos.com/flannel/docs/latest/flannel-config.html

I'm curious to see what solution you will come up with. I'm setting up a cluster and was thinking of the same issues.

Did you set up a private network for the cluster communication outside of the rest of the LAN? I was wondering if you could give the entire cluster the same IP facing LAN and with that setup.

Can you use your Dockerfile to build a Docker image, then push that Docker image to the Docker hub? Then in your fleet unit file for your exec command you can have a docker run command that starts a container based on the image. You'll also want to define an ExecStartPre to pull the image and a few more commands.

There is a good example file on this page https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/