On Wed, Jul 24, 2019 at 12:18 PM Fox, Kevin M <kevin....@pnnl.gov> wrote:
> So, last I heard OpenShift was starting to modularize, so it could load > the OpenShift parts as extensions to the kube-apiserver? Has this been > completed? Maybe the idea below of being able to deploy vanilla k8s is > workable as the OpenShift parts could easily be added on top? > OpenShift in 3.x was a core control plane plus 3-5 components. In 4.x it's a kube control plane, a bunch of core wiring, the OS, the installer, and then a good 30 other components. OpenShift 4 is so far beyond "vanilla kube + extensions" now that while it's probably technically possible to do that, it's less of "openshift" and more of "a kube cluster with a few APIs". I.e. openshift is machine management, automated updates, integrated monitoring, etc. > > Thanks, > Kevin > ________________________________________ > From: dev-boun...@lists.openshift.redhat.com [ > dev-boun...@lists.openshift.redhat.com] on behalf of Michael Gugino [ > mgug...@redhat.com] > Sent: Wednesday, July 24, 2019 7:40 AM > To: Clayton Coleman > Cc: users; dev > Subject: Re: Follow up on OKD 4 > > 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. 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. Atomic was dead simple to build > ostree repos for. I'd prefer to have ignition be opt-in. 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. > > I'd like to see OKD be distro-independent. Obviously Fedora should be > our primary target (I'd argue Fedora over FCoS), but I think it should > be true upstream software in the sense that apache2 http server is > upstream and not distro specific. To this end, perhaps it makes sense > to consume k/k instead of openshift/origin for okd. OKD should be > free to do wild and crazy things independently of the enterprise > product. Perhaps there's a usecase for treating k/k vs > openshift/origin as a swappable base layer. > > It would be nice to have a more native kubernetes place to develop our > components against so we can upstream them, or otherwise just build a > solid community around how we think kubernetes should be deployed and > consumed. Similar to how Fedora has a package repository, we should > have a Kubernetes component repository (I realize operatorhub fulfulls > some of this, but I'm talking about a place for OLM and things like > MCD to live). > > I think we could integrate with existing package managers via a > 'repo-in-a-container' type strategy for those not using ostree. > > As far as slack vs IRC, I vote IRC or any free software solution (but > my preference is IRC because it's simple and I like it). > > On Sun, Jul 21, 2019 at 12:28 PM Clayton Coleman <ccole...@redhat.com> > wrote: > > > > > > > > On Sat, Jul 20, 2019 at 12:40 PM Justin Cook <jhc...@gmail.com> wrote: > >> > >> Once upon a time Freenode #openshift-dev was vibrant with loads of > activity and publicly available logs. I jumped in asked questions and Red > Hatters came from the woodwork and some amazing work was done. > >> > >> Perfect. > >> > >> Slack not so much. Since Monday there have been three comments with two > reply threads. All this with 524 people. Crickets. > >> > >> Please explain how this is better. I’d really love to know why IRC > ceased. It worked and worked brilliantly. > > > > > > Is your concern about volume or location (irc vs slack)? > > > > Re volume: It should be relatively easy to move some common discussion > types into the #openshift-dev slack channel (especially triage / general > QA) that might be distributed to other various slack channels today (both > private and public), and I can take the follow up to look into that. Some > of the volume that was previously in IRC moved to these slack channels, but > they're not anything private (just convenient). > > > > Re location: I don't know how many people want to go back to IRC from > slack, but that's a fairly easy survey to do here if someone can volunteer > to drive that, and I can run the same one internally. Some of it is > inertia - people have to be in slack sig-* channels - and some of it is > preference (in that IRC is an inferior experience for long running > communication). > > > >> > >> > >> There are mentions of sigs and bits and pieces, but absolutely no > progress. I fail to see why anyone would want to regress. OCP4 maybe > brilliant, but as I said in a private email, without upstream there is no > culture or insurance we’ve come to love from decades of heart and soul. > >> > >> Ladies and gentlemen, this is essentially getting to the point the > community is being abandoned. Man years of work acknowledged with the > roadmap pulled out from under us. > > > > > > I don't think that's a fair characterization, but I understand why you > feel that way and we are working to get the 4.x work moving. The FCoS team > as mentioned just released their first preview last week, I've been working > with Diane and others to identify who on the team is going to take point on > the design work, and there's a draft in flight that I saw yesterday. Every > component of OKD4 *besides* the FCoS integration is public and has been > public for months. > > > > I do want to make sure we can get a basic preview up as quickly as > possible - one option I was working on with the legal side was whether we > could offer a short term preview of OKD4 based on top of RHCoS. That is > possible if folks are willing to accept the terms on try.openshift.com in > order to access it in the very short term (and then once FCoS is available > that would not be necessary). If that's an option you or anyone on this > thread are interested in please let me know, just as something we can do to > speed up. > > > >> > >> > >> I completely understand the disruption caused by the acquisition. But, > after kicking the tyres and our meeting a few weeks back, it’s been pretty > quiet. The clock is ticking on corporate long-term strategies. Some of > those corporates spent plenty of dosh on licensing OCP and hiring > consultants to implement. > >> > >> > >> Red Hat need to lead from the front. Get IRC revived, throw us a bone, > and have us put our money where our mouth is — we’ll get involved. We’re > begging for it. > >> > >> Until then we’re running out of patience via clientele and will need to > start a community effort perhaps by forking OKD3 and integrating upstream. > I am not interested in doing that. We shouldn’t have to. > > > > > > In the spirit of full transparency, FCoS integrated into OKD is going to > take several months to get to the point where it meets the quality bar I'd > expect for OKD4. If that timeframe doesn't work for folks, we can > definitely consider other options like having RHCoS availability behind a > terms agreement, a franken-OKD without host integration (which might take > just as long to get and not really be a step forward for folks vs 3), or > other, more dramatic options. Have folks given FCoS a try this week? > https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/. > That's a great place to get started > > > > As always PRs and fixes to 3.x will continue to be welcomed and that > effort continues unabated. > > _______________________________________________ > > dev mailing list > > d...@lists.openshift.redhat.com > > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > > > -- > Michael Gugino > Senior Software Engineer - OpenShift > mgug...@redhat.com > 540-846-0304 > > _______________________________________________ > dev mailing list > d...@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
