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
> > dev@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
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
dev mailing list

Reply via email to