[throwaway9147]

A competing product (Harbor) is already open-source and part of CNCF. Quay wouldn't have had any future if it was to stay proprietary.

Regarding RedHat (or IBM) truly committing to open-source, I'll believe when OpenShift 4.x is open-sourced.

[ecnahc515]

Openshift 4.x is open-source. I'm guessing what your speaking towards is the fact that there is no prebuilt distribution of it that doesn't require a subscription, ie: OKD, which is something being worked on. Clayon started off the conversation on this back in June: https://lists.openshift.redhat.com/openshift-archives/users/...

But everything it's being built with is entirely FOSS. Making OKD happen is a high priority and is being worked on.

From my understanding, most of it's been blocked on Fedora CoreOS being at a state that it can be used for OKD and just putting resources onto setting up the automation for building everything for OKD.

Remember that Openshift 4.x fundamentally changed how Openshift does updates and that affects OKD a lot. Claytons email touches on this quite a bit.

Disclosure: I work at Red Hat, on projects related to Openshift.

[throwaway9147]

> Openshift 4.x is open-source.

That's great to hear. My mistake then, last time I've opened http://github.com/openshift/origin, I saw OpenShift 3.11 even though latest release was 4.2 at the time. From that, and given the fact that all other RedHat products are upstream first, I've made a conclusion that OpenShift 4 is no longer open-source.

> From my understanding, most of it's been blocked on Fedora CoreOS being at a state that it can be used for OKD and just putting resources onto setting up the automation for building everything for OKD.

What's the difference between OKD and OpenShift? Why does OKD use Fedora CoreOS, while OpenShift doesn't? Is it not the same code?

> Remember that Openshift 4.x fundamentally changed how Openshift does updates and that affects OKD a lot. Claytons email touches on this quite a bit.

Don't know Clayton or seen his email. I'm confused why would OKD use a different code than OpenShift. I though that the only difference between OKD and OpenShift would be the subscription.

[smarterclayton]

We needed fedora coreos. OpenShift used RHEL CoreOS. It took longer for fedora coreos because we also wanted fedora coreos to be a sufficient replacement for ContainerLinux. That integration started passing CI with openshift today.

Readme updates and lots of this stuff need to be done - we left the readme at 3.11 because that was a coherent install (vs the more work in progress of fedora coreos).

Every bit of source code was there (and developed in the open), but it wasn’t all “pulled together”

[throwaway9147]

Thank you for clarification and for all your hard work.

I'm looking forward to OKD4 and I will be checking out Fedora CoreOS soon.

[ibotty]

Is there already some documentation on how to play with it?

[smarterclayton]

Coming very soon - hopefully ready for KubeCon

[ecnahc515]

Clayton already answered some of this, but I also have some other ways of saying the same thing.

OKD 4 uses Fedora CoreOS for the same reason that OKD 3.11 used CentOS instead of RHEL. For better or worse, they're built and maintained by different systems and/or people, and we simply can't just make OKD use a RHEL derivative due to how support and subscriptions work.

Functionally, they should be nearly identical, but in practice, they're two different pieces of software and they're maintained and built in different systems, much like how Fedora, and CentOS are managed separately from RHEL. The differences mostly come to where packages come from and what systems built them.

The code for OCP/OKD is the same, the major difference is how it's built and released and the OS (RHEL CoreOS vs Fedora CoreOS), and potentially the upgrade graphs supported via over the air updates.

As to who Clayton is: he is basically one of the the main architects for Openshift since basically the beginning (I forget if it goes back to prior to v3).

[slenk]

Its OSS, but it is definitely not free software.

Lets be honest, nothing redhat gives out is actually free.

[freedomben]

I think I'm a lot more benefit-of-the-doubt than you, but I agree completely with what you said.

Red Hat is very committed to putting the necessary infrastructure and organization in place around projects before they open source to make sure that the code isn't just available but can actually use community contributions. I don't have any inside info on this, but I wouldn't be surprised if OpenShift 4 is just waiting for that, or possibly to be in a stable enough state that the community can contribute.

Of course it's possible also that RH is keeping it closed for other reasons as well such as avoiding tipping their hand to competitors until their end goal is realized or something like that. I guess the point is I don't know, but given Red Hat's history of open sourcing even valuable acquisitions, I have faith that they will with OpenShift 4 as well.

[throwaway9147]

> Red Hat is very committed to putting the necessary infrastructure and organization in place around projects before they open source to make sure that the code isn't just available but can actually use community contributions.

OpenShift went from open-source to closed-source. The infrastructure and organization was already in place.

> or possibly to be in a stable enough state that the community can contribute.

I would say that it's stable enough for all RedHat customers who pay for it.

> I guess the point is I don't know, but given Red Hat's history of open sourcing even valuable acquisitions, I have faith that they will with OpenShift 4 as well.

I have no doubts that old RedHat would do it, but IBM might have a different approach.

[throwaway9147]

ignore my above comment, I've jumped to premature conclusions.

[joshberkus]

True, but it's been a goal to open source Quay from before Red Hat acquired CoreOS. The Quay team has always wanted to go community OSS, and it's been Red Hat's policy since acquisition to help them. There were just a whole bunch of prerequisites to iron out first.

And now users are in a much better place, because they have multiple choices of container registry, which will hopefully drive innovation.

[throwaway9148]

Another great project my org is in the process of migrating to is Kraken. We’re migrating to that from after a bad experience with Harbor.

[throwaway9147]

I don't have any experience with Harbor so can't comment on its architecture, my argument was purely about there being an existing, highly popular, open source solution backed by CNCF. Can you share more details about what's so bad about Harbor architecture?

[thebouv]

Curious what your experience was. Been using harbor for a couple months and have no issues. BUT we're not using it in a very heavy environment.