Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
alignment/comparison with coreos/toolbox #8
Let's discuss overlap with coreos/toolbox@598df78
One broad concern I have here is the very name of the project; in Fedora we go to a lot of effort to have most of "Fedora" branding inside
This one seems to assume a full desktop login and be run as non-root, where as for the coreos-toolbox we instead assume the user is running as root on a console, and should have full system wide privileges.
But really...the overlap in implementation and scope is big.
My 2c is that we call it "coreos-toolbox" as a project name, but just "toolbox" implicitly when discussing in a Fedora/CoreOS context.
My initial impetus to file this issue is https://pagure.io/workstation-ostree-config/pull-request/106 - adding something to the "base image" implies a fairly long term of support.
(tl;dr: I am happy to switch to a downstream agnostic name.)
Well, this isn't about bits of trademarks, configuration, names and version numbers that define a specific Fedora release, though. It's more like fedora-packager, which has a bunch of
Even though a toolbox container is a generic concept, the mix of upstream technologies (ie., Buildah, Podman), and downstream consumers (eg., Fedora Silverblue) make it uniquely "Fedora". It probably already works on, say, Debian, but I haven't tested it, nor is it the primary reason for the tool to exist. At least it's not my priority today.
That said, if a
(tl;dr: I am aware of CoreOS' needs and happy to address those.)
Well, it wasn't really a secret that we are working on a toolbox for Silverblue and what our needs are. :)
We have discussed this in
I am aware that Fedora CoreOS' needs are different from Silverblue's. My impression was that we are happy to share as much of the toolbox as we can for the two flavours. However, I haven't heard anything from the CoreOS team after the initial discussion, and I don't know what the current plans or priorities are. Just the other day, I dropped a couple of comments about the current status of
Meanwhile, in Silverblue land, the toolbox is pretty crucial. Otherwise we can't use Silverblue as a development environment, and I really want to use my shiny XPS 13 running Silverblue as much as I can. :) So we had to choose a name and move forward.
One of the reasons I didn't fork and continue with the original repository, was because I wasn't sure what to do with the governance and process related bits in there. A code of conduct, contribution guidelines, etc. are important things to have, but I also wanted to make it clear that this is happening under the Fedora banner. Not knowing exactly how the Fedora banner looks like, I didn't want to just
Secondly, since the underlying tools were going to be completely different, it meant that the script would have to be rewritten. Hence I was not too worried about preserving the Git history.
(Hm, so if we drop
Yep, I heard there was a discussion, sorry I am only now circling back to this after seeing the Silverblue PR.
Agree, though I don't feel blocked myself right now having my own custom scripts for this, I do think we need to have an opinionated out of the box solution too.
Now, I find myself agreeing with this comment:
So, I work on Red Hat CoreOS and...I am not entirely sure that when we ship the tool should default to Fedora userspace. There are a whole lot of implications to that - some good, some bad.
Now particularly when you're talking about the command line, Fedora is packages and particularly given the default to a Fedora userspace, calling it "fedora-toolbox" does make sense. But that said I still have concerns over the branding.
The idea of solving two problems at once by merging the coreos-toolbox and fedora-toolbox and just calling it "toolbox" hence has a lot of appeal.
Well, you are one of those very special people who are well-versed in both containers and modern graphical OSes. Hapless mortals have been known to struggle with little things like leaking in the display server socket, and so on. :)
Yes, I like Dusty's idea too.
However, I don't know what troubleshooting exactly looks like in this case.
To be fair, my understanding of development is also skewed towards "should be possible to do jhbuild-style development", which is basically "install some tools from the distribution, build and install things into a separate prefix and run them". I'd really appreciate it if people with different workflows and development setups would try it out and give feedback.
This seems a bit like
My assumption was that Fedora CoreOS/Silverblue and Red Hat CoreOS/Silverblue would share the usual relationship between Fedora and RHEL. Admittedly, Red Hat CoreOS is probably a very real thing while Red Hat Silverblue is probably just vapourware. :)
Yes, I understand. My operating principal has been to mimic a familiar RPM-based environment with the toolbox. So, I'd expect a Fedora toolbox to have Fedora RPMs, and a RHEL toolbox to have RHEL RPMs. At least by default, because one can always fiddle with the flags and create a Fedora toolbox on RHEL and what not. Just like the toolbox defaults to the host's
It's just that I work on Silverblue, and while Fedora Silverblue is a real thing, I have never even heard of Red Hat Silverblue. Hence the bias towards all things Fedora comes from a desire to keep it simple and get the ball rolling. I certainly don't want to enforce Fedora content on RHEL users by default.
I am apprehensive of claiming a spot in the global namespace. Especially for the Git repository because
so the scope of this program isn't just for people working on fedora, right? it's primarily for people who happen to use fedora to get completely unrelated work done. fedpkg is for people packaging programs for fedora. it's for us, not for our users. this program is for our users.
Yes, that's right.
However, at least for the time being, we are not focused on making this work on every single distribution out there; and some bits of configuration (eg., the URL of the OCI image registry, the name of the default image, etc.) might change between Fedora and RHEL.
From the other issue (regarding coreos v. silverblue):
Yes, I agree. Apologies for mis-interpreting the initial discussions. Since the coreos use case was much smaller I opted to create a very simple toolbox to build into our existing pipeline. Moving forward I think consolidating the two would definitely make sense.
So I can only speak to what RHCOS originally envisioned to use the toolbox for: essentially run a debug tool inside a failing host in a openshift cluster. In that sense the
Alternatively, the fedora toolbox can just by default run a fedora image, and the rhel toolbox to default to a rhel image would probably work as well?
The main reasoning from a coreos perspective is that that was the chosen name for CL: https://github.com/coreos/toolbox I have no strong feelings either way regarding naming.
I'll try out @debarshiray's toolbox on coreos systems later this week and see if there's any compatibility issues. Again, apologies for the lack of follow up, and thanks for trying to consolidate!
Okay, my take is that's not a strong enough reason to include fedora in the name. I mean we don't call firefox fedora-firefox because it's default start page is start.fedoraproject.org. Distros are expected to do per distribution customizations of software, I think.
I don't think it's a big issue if it doesn't work on other distros either. I mean that's the responsibility of other distros, if they see the value. of course, if it explicitly should be fedora only that's a different story.
A couple of initial questions:
The customized image that's locally created with
This comes from commit d7219ba
Usually file descriptor 42 points at
I am curious why it doesn't work on CoreOS, though.
Interesting. Was it with local changes in your tree?
I just happened to try the toolbox with
Looks like a
Umm... I guess it depends on the specific use-case?
So, where do we stand with the naming issue? I am fine with dropping the
Or have we chosen to swallow the
I have no strong feelings either way and defer to more experienced folks regarding naming, but I think it's looking like the generic "toolbox" name is in the majority?
Sorry for the delayed response, I am on a trip until next week. I'll look into the issues above when I'm back.