[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Follow up on OKD 4



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?

Thanks,
Kevin
________________________________________
From: dev-bounces lists openshift redhat com [dev-bounces lists openshift redhat com] on behalf of Michael Gugino [mgugino 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 <ccoleman redhat com> wrote:
>
>
>
> On Sat, Jul 20, 2019 at 12:40 PM Justin Cook <jhcook 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
mgugino redhat com
540-846-0304

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]