> On Jul 24, 2019, at 9:14 PM, Michael Gugino <mgug...@redhat.com> wrote:
> I think what I'm looking for is more 'modular' rather than DIY.  CVO
> would need to be adapted to separate container payload from host
> software (or use something else), and maintaining cross-distro
> machine-configs might prove tedious, but for the most part, rest of
> everything from the k8s bins up, should be more or less the same.
> 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.  And instead of 'rebases
> ostree', we could pull down a container that acts as a local repo that
> contains all the bits you need to upgrade your host across releases.
> Users could do things to break this workflow, but it should otherwise
> work if they aren't fiddling with the hosts.  The MCD payload happens
> to embed an ignition payload, but it doesn't actually run ignition,
> just utilizes the file format.
> From my viewpoint, there's nothing particularly special about ignition
> in our current process either.  I had the entire OCP 4 stack running
> on RHEL using the same exact ignition payload, a minimal amount of
> ansible (which could have been replaced by cloud-init userdata), and a
> small python library to parse the ignition files.  I was also building
> repo containers for 3.10 and 3.11 for Fedora.  Not to say the
> OpenShift 4 experience isn't great, because it is.  RHEL CoreOS + OCP
> 4 came together quite nicely.
> I'm all for 'not managing machines' but I'm not sure it has to look
> exactly like OCP.  Seems the OCP installer and CVO could be
> adapted/replaced with something else, MCD adapted, pretty much
> everything else works the same.

Sure - why?  As in, what do you want to do?  What distro do you want
to use instead of fcos?  What goals / outcomes do you want out of the
ability to do whatever?  Ie the previous suggestion (the auto updating
kube distro) has the concrete goal of “don’t worry about security /
updates / nodes and still be able to run containers”, and fcos is a
detail, even if it’s an important one.  How would you pitch the

>> On Wed, Jul 24, 2019 at 12:05 PM Clayton Coleman <ccole...@redhat.com> wrote:
>>> On Wed, Jul 24, 2019 at 10:40 AM Michael Gugino <mgug...@redhat.com> 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.  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.
>> That’s feedback that’s probably something you should share in the fcos 
>> forums as well.  I will say that I find the OCP + RHEL experience 
>> unsatisfying and doesn't truly live up to what RHCOS+OCP can do (since it 
>> lacks the key features like ignition and immutable hosts).  Are you saying 
>> you'd prefer to have more of a "DIY kube bistro" than the "highly 
>> opinionated, totally integrated OKD" proposal?  I think that's a good 
>> question the community should get a chance to weigh in on (in my original 
>> email that was the implicit question - do you want something that looks like 
>> OCP4, or something that is completely different).
>>> 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.
>> That’s even more dramatic a change from OKD even as it was in 3.x.  I’d be 
>> happy to see people excited about reusing cvo / mcd and be able to mix and 
>> match, but most of the things here would be a huge investment to build.  In 
>> my original email I might call this the “I want to build my own distro" - if 
>> that's what people want to build, I think we can do things to enable it.  
>> But it would probably not be "openshift" in the same way.
>>> 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).
>> MCD is really tied to the OS.  The idea of a generic MCD seems like it loses 
>> the value of MCD being specific to an OS.
>> I do think there are two types of components we have - things designed to 
>> work well with kube, and things designed to work well with "openshift the 
>> distro".  The former can be developed against Kube (like operator hub / olm) 
>> but the latter doesn't really make sense to develop against unless it 
>> matches what is being built.  In that vein, OKD4 looking not like OCP4 
>> wouldn't benefit you or the components.
>>> I think we could integrate with existing package managers via a
>>> 'repo-in-a-container' type strategy for those not using ostree.
>> A big part of openshift 4 is "we're tired of managing machines".  It sounds 
>> like you are arguing for "let people do whatever", which is definitely valid 
>> (but doesn't sound like openshift 4).
>>> 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).
> --
> Michael Gugino
> Senior Software Engineer - OpenShift
> mgug...@redhat.com
> 540-846-0304

dev mailing list

Reply via email to