Re: Follow up on OKD 4
On Wed, Jul 24, 2019, at 10:40 AM, Michael Gugino wrote: > I tried FCoS prior to the release by using the assembler on github. > Too much secret sauce in how to actually construct an image. I > thought atomic was much more polished, not really sure what the > value-add of ignition is in this usecase. The OpenShift installer and Machine Config Operator are built around Ignition. > Just give me a way to build > simple image pipelines and I don't need ignition. To that end, there > should be an okd 'spin' of FCoS IMO. Yes, this is what https://hackmd.io/ZOQo-1VnRNOrgIcGosq29A proposes. > Atomic was dead simple to build > ostree repos for. I'd prefer to have ignition be opt-in. This is a bit of a side discussion, but rpm-ostree hasn't changed at all; we still support e.g. using it with Anaconda upstream. But it's also true that the focus is now on the "CoreOS model" which pairs (Ignition, ostree) and that's what coreos-assembler is for. > Since we're > supporting the mcd-once-from to parse ignition on RHEL, we don't need > ignition to actually install okd. To me, it seems FCoS was created > just to have a more open version of RHEL CoreOS, and I'm not sure FCoS > actually solves anyone's needs relative to atomic. It feels like we > jumped the shark on this one. One pitch for Ignition is that it unifies bare metal and cloud provisioning - in RHEL you have kickstart vs cloud init. Again, the OpenShift installer (and MCO) today is built on top of this - if you're doing a bare metal PXE setup it works almost exactly the same as an AWS AMI boot. > I'd like to see OKD be distro-independent. > MCD is good software, but there's not really much going on there that can't > be ported to any other OS. MCD downloads a payload, extracts files, rebases > ostree, reboots host. You can do all of those steps except 'rebases ostree' > on any distro. First, you're missing a bit of the interesting bits around "extracts files" because the MCO correctly handles *state transitions* between Ignition configs (e.g. ensuring that old files are deleted), and this relies on it being provisioned into a known state that wasn't written by a mix of e.g. Kickstart and Puppet/Ansible or whatever. And the OS updates...that's just the start. Nowadays when I'm talking about RHCOS in the context of OpenShift 4, I usually start talking about the MCO first - and in particular that the MCO combines with RHCOS to make a "Kubernetes native OS". Concrete example; we now support setting FIPS mode: https://github.com/openshift/machine-config-operator/pull/889 (As well as generic kernel arguments) But this is all still just the beginning for the MCO, next up may be SELinux: https://github.com/openshift/machine-config-operator/issues/852 And you get the idea. Obviously, we could support kernel arguments on e.g. Ubuntu too. And FIPS, etc. But...the engineering cost starts to add up. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: Proposal: Deploy and switch to Discourse
On Fri, Jul 12, 2019, at 10:19 AM, Neal Gompa wrote: > Fedora didn't shut down its users@ list when it deployed > discussions.fp.o. And adoption of Discourse in Fedora hasn't been very > high outside of the Silverblue/CoreOS bubble. Eh, but the traditional Fedora community has a pretty high level of, hmm..how to describe it...people likely to be "power email" users, the types of people who know how to set up email filtering, may even run their own email servers in 2019, etc. That said I think Discourse is "okay enough" for those people, even though it's more "web page" than "email list" (where as mailman 3 is more the other way around). > I'm not opposed to the idea of having an additional channel for user > support with Discourse on okd.io, though. We already have too many channels, adding more isn't going to help. The existing lists aren't high traffic, and my high level impression is the people posting here are going to be fine with Discourse. The reason I mentioned commons Slack first is because it's the primary entrypoint, and I think Discourse is a better *primary* entrypoint. (And not responding directly to Neil here) - Let's please keep proposals for any changes to the *real time* stuff like Slack/IRC out of this discussion because I'd like to focus on a clear and "direct" goal (Discourse replacing mailman) - anything else scope creeps this a lot. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Proposal: Deploy and switch to Discourse
Hi, I think the Common's use of Slack is not a good match for "support". Requiring an invitation is also an impediment to quickly asking questions. Further Slack is proprietary, and also any discussion there won't be easily found by Google. On the other hand we have these mailing lists, which are fine but they're traditional mailing lists with all the tradeoffs there. I propose we shut down the user@ and dev@ lists and deploy a Discourse instance, which is what the cool kids ;) are doing: https://discussion.fedoraproject.org/ http://internals.rust-lang.org/ etc. Discourse is IMO really nice because for people who want a mailing list it can act like that, but for people who both want a modern web UI and most importantly just want to drop in occasionally and not be committed to receiving a stream of email, it works a lot better. Also importantly to me it's FOSS. I would also personally lean towards not using Slack too but I see that as a separate discussion - it's real time, and that's a distinct thing from discourse. If we get a lot of momentum in our Discourse though over Slack we can consider what to do later. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: OKD 4 - A Modest Proposal
On Wed, Jun 26, 2019, at 1:10 PM, Colin Walters wrote: > The tricky thing here is...if we want this to work the same as OpenShift 4/OCP > with RHEL CoreOS, then what we're really talking about here is a *derivative* > of FCOS that for example embeds the kubelet from OKD. And short term > it will need to use Ignition spec 2. There may be other things I'm > forgetting. It was pointed out to me that there is also some relevant discussion in this issue: https://github.com/coreos/fedora-coreos-tracker/issues/93 ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: OKD 4 - A Modest Proposal
On Thu, Jun 20, 2019, at 5:20 PM, Clayton Coleman wrote: > Because the operating system integration is so critical, we need to > make sure that the major components (ostree, ignition, and the kubelet) > are tied together in a CoreOS distribution that can be quickly > refreshed with OKD - the Fedora CoreOS project is close to being ready > for integration in our CI, so that’s a natural place to start. That > represents the biggest technical obstacle that I’m aware of to get our > first versions of OKD4 out (the CI systems are currently testing on top > of RHEL CoreOS but we have PoCs of how to take an arbitrary ostree > based distro and slot it in). The tricky thing here is...if we want this to work the same as OpenShift 4/OCP with RHEL CoreOS, then what we're really talking about here is a *derivative* of FCOS that for example embeds the kubelet from OKD. And short term it will need to use Ignition spec 2. There may be other things I'm forgetting. Concretely for example, OKDFCOS (to use the obvious if unwieldy acronym) would need to have its own uploaded "bootimages" (i.e. AMIs, PXE media etc) that are own its own version number/lifecycle distinct from (but derived from) FCOS (and OKD). This is completely possible (anything is in software) but the current team is working on a lot of things and introducing a 3rd stream for us to maintain would be a not at all small cost. On the other hand, the benefit of doing so (e.g. early upstream kernel/selinux-policy/systemd/podman integration testing with kubernetes/OKD) might be worth it alone. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Why are most openshift/origin releases on github tagged pre-release?
Under https://github.com/openshift/origin/releases it looks like there was never a "non-prerelease" 1.5. Now we're on the train to 3.6 (which makes sense to me). Currently in Fedora, all versions are 1.4: https://bodhi.fedoraproject.org/updates/?packages=origin The CentOS PaaS SIG built 1.5rc: http://cbs.centos.org/koji/buildinfo?buildID=16916 I'd like to update Fedora at least since I really want a lot of the enhancements in `oc cluster up` lately. But what should I update it to? I guess we should at least match the PaaS SIG version, but I'm wondering whether Fedora should just start tracking the 3.6 alphas? ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: OpenShift Origin v1.2.0 released, along with the development drop of v1.3.0-alpha.1
In case anyone else is curious for more details, the links appear to be: On Wed, May 25, 2016, at 10:38 PM, Clayton Coleman wrote: > Stay tuned - 1.3 has a lot of exciting changes, and the next alpha.2 > will include PetSets https://github.com/kubernetes/kubernetes/issues/260 > init containers https://github.com/kubernetes/kubernetes/pull/23567 ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
