I recognize your username because I met you at Kubernetes Community Day AMS, after Helm Summit, when you told everyone your username from up on the stage...
By the way I loved your talk "Convergence of Communities" and everything about the Jellyfish modeling, so for the benefit of anyone who maybe does not know who you are, or why you posted this one-liner... this is Diane, Director of Community Development at RedHat, and you can find that talk on YouTube.
So, thanks for doing this!
https://docs.projectquay.io/deploy_quay.html
"For a Project Quay Registry installation (appropriate for non-production purposes), you need one system (physical or virtual machine) that has the following attributes:
Red Hat Enterprise Linux (RHEL): Obtain the latest Red Hat Enterprise Linux server media from the Downloads page and follow instructions from the Red Hat Enterprise Linux 7 Installation Guide.
Valid Red Hat Subscription: Obtain a valid Red Hat Enterprise Linux server subscription.So, is it truly tied to RHEL and a subscription, or is that page just making me FEEL that way?
Annoying either way. :/
So guessing the docs will slowly shift to RHEL8 and podman.
Why does a container registry need so many resources?
Second, I think it would help to know why you think a container registry wouldn't need a moderate amount of resources.
I don't necessarily disagree that the resources could be lower at the minimum (and in fact, I recall they are quite a bit lower than this when running it on your laptop without any load), but is this really anything unexpected?
It's written in Python so it's not going to be as efficient as Go or C++ but it certainly isn't Java levels of resources being requested here.
High resource requirements mean that I need to spend more on compute, whether that means paying a cloud provider for a beefier instance, or spending more money on hardware and electricity.
Spinning up a cloud VM with 4GB for a year is a bit more than beer money though.
Reminds me of installing gitlab. Requirement 8GB...for a basic install. After a bunch of crashes (on a 8gb VM) I went with vanilla git.
https://www.jfrog.com/confluence/plugins/servlet/mobile?cont...
For those that use LDAP authentication for this, it makes is a much smaller attack vector.
The per-team "organizations" is very nice and allows you to give teams their own flexibility while still running things within your own firewalls (on-prem or in a vpc). It is an alternative to docker hub with a lot of really nice features.
The ability to do scheduled mirroring of images from other registries (such as docker hub) and replication between different instances of quay is also really beneficial.
Disclaimer: commercial quay enterprise user for some time.
Disclaimer: I work for Red Hat but have been a fan decades longer than I've worked there.
So, what is Quay? And why the information pages assume everyone knows what it is?
Edit: I called it Kway myself and googled it after getting puzzled looks from my UK peers. The referenced article says "key" is the older pronunciation but either is acceptable.
Disclaimer: Named, cofounded, and now engineering lead of Quay
(I assume this has carried through to Red Hat.)
Still, it’s great to see quay make it out into the open.
It was in a mostly stagnant state, a release once in a while, and now it's going regular and strong.
The thing is, after things get the "CNCF" stamp they kinda go viral and become the "de facto" standard.
This means that Harbor would become the most usual way to run a private registry and thus Quay would lose ground (=> harder to sell).
Source: just implemented Harbor at work. Quay would probably have been better (probably "production ready") but Harbor was free & open source.
Not to take anything away from the accomplishments of the Quay team or their contribution, there is definitely value in having more than one kid on the block when it comes to open-source solutions for problems like this. I think the tendency is to push for "one solution to rule them all" and that kind of approach can stifle innovation pretty hard.
I'm not sure there's any relevance between this announcement and that one, as Harbor has been in the incubator since about 12 months ago from what I can tell, and was sandbox before that. But it appears to be another mature solution in the same space with many of the same features, if that isn't something worth noting I can't understand why not!
To your point, it would be great if the comment was a bit more substantive.
We've been discussing and working on this since the CoreOS acquisition. My good friend and Consulting colleague wrote a lot of the Operator code now used for installation.
They're note using Slack!
It's my premise that the author of that press release doesn't know the difference between "premise" and "premises." I know we have a habit in American English to evolve the meaning of words faster than any other language but surely IBM's press team could offer to proof-read things like this before posting.
https://www.merriam-webster.com/dictionary/premise
(And yes, I die inside a bit when someone on NPR ends a sentence with a preposition...)
1.) There are arguments but no definitive justification for choosing between on-premise and on-premises.
2.) A lot of what gets lumped under on-prem is not actually on your premises anyway. It's in a colo or a managed hosting provider, etc.
The issue is that OSS is the only way to compete with the cloud. Quay would die without 3rd party contributions vs Amazon, Google, Microsoft.
(Disclaimer: Red Hatter since almost 15 years. I never doubted for a second that we would open source what we buy. Ansible, 3Scale, CoreOS, we have a long history of sticking to our principles)
Regarding RedHat (or IBM) truly committing to open-source, I'll believe when OpenShift 4.x is open-sourced.
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.
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.
And now users are in a much better place, because they have multiple choices of container registry, which will hopefully drive innovation.
In fact, a version without the Container Scanning bits and some of the user management is the default internal registry in OpenShift 4.x.
(yes, that was in reference to a PC, not a server.)
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.
If you want to just test it, why not use a VritualBox VM or similar?
To illustrate:
My employer gives me $150 cloud credits. 20 USD seems like pocket change
Me paying out of pocket...20 that's like 2x netflix but fine whatever.
Me being part of the other 95% of the world...unaffordable.
But really my main objection here is why. To borrow my gitlab example...how does adding a interface on top of core software up requirement from zilch to 8 gb? Like wtf is going on underneath that bonnet. It's not doing the heavy lifting - git is doing that. So for a SINGLE user install...whats that 8GB doing? 8GB worth of UI? It's installing via CLI for gods sake...
Python has the GIL meaning parallelism comes at the cost of increased memory and CPU consumption because it's typically going to spin up multiple copies of the Python interpreter and your application. This is also true of Ruby, so it applies both to Gitlab and Quay.
Quay uses Gunicorn which uses pre-fork model which means spinning up multiple processes of Quay which can lead to increased CPU and memory requirements. Obviously you need multiple cores to take proper advantage of multiple processes, and multiple processes each result in multiple copies of the same application running, thus more memory.
This is kind of a fact of using something like Python or Ruby unless you design your application to use an event driven architecture with something like twisted, tulip, async, tornado, etc. Even then, unless you have async versions of the libraries your using (eg: your DB driver) that won't necessarily remove your need for multiple processes.
English is not a good place to go if you are looking for intuitive pronunciation.
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.
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”
I'm looking forward to OKD4 and I will be checking out Fedora CoreOS soon.
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).
Lets be honest, nothing redhat gives out is actually free.
However, when I worked at SUSE a running joke was: as long as you love using it we don't care how you pronounce it.
Normally I'd assume it's not working because I'm doing something wrong. But this is their omnibus installer - it's a single line.
As a devops, I rely heavily on Hashi and Ansible and Chef and so many other tools. However, their enterprise offerings are both too expensive and also too big for what I need. I can't get my employer to just donate money, so what can I simply and easily buy to fund the effort while still getting some value?
Grafana, for example, with paid plugins has made this easier: the moment you need a bit more, you pay for it. We need to extend this model out somewhat, get these vendors to offer more premium functionality - generally in the form of charging for integrations with other closed source software. That if you stay open the whole way yourself you can probably do the whole thing for free; conversely, if you have money for Datadog or whatever other service, then you probably have money to attach Grafana to Datadog too.
The real money is with the organizations that feel the need (for many good and bad reasons) to pay millions of dollars for support, consulting, and the like. They don't care about the people that are looking to save a few grand on licenses.
It's possible that the existence of CentOS is partially keeping RHEL viable. Maybe Fedora would be enough to do that, but overall CentOS probably contributes to RHELs demand, rather than detracting.
I hope for all of us that doesn’t happen anytime soon, but IBM acquired Redhat, not the other way around... plenty of sun folks learned that the hard way.
P.S. I also agree with other people posting here. Red Hat is chock full of people who are absolutely looney about Open Source. It's at the heart of everything we do.
AWX isn't a trivial or unimportant product. For deployments of scale it's very important. It would also have been very easy to hoard the code and not release it, so the fact that RH did is impressive to me.
Having not tried to use open source AWX I'll take your word for the state of it. That saddens me greatly, and RH should do better. RH normally works pretty hard to avoid exactly that, but nobody is perfect (not making an excuse, just acknowledging failure).
Have you tried to contribute to AWX and had a bad experience?
Arguably a lot of OS progress that we are seeing today, especially in the enterprise, is a direct result of IBM’s decades old investments in tools like Eclipse, which was probably the first enterprise grade open source development software, but more importantly, by promoting OS in the enterprise in the late 90s and early 2000s at a time when MS FUD about Linux was at an all time high.
