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