-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
alignment/comparison with coreos/toolbox #8
Comments
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. |
A bit of background on the new coreos-toolbox: it was designed to be a very simple admin/debug container with full privileges, essentially a port from the old one (for CL) but for RHCOS/FCOS systems. In that sense the scope is much smaller. |
(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. Hence, the 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.
As I mentioned earlier, 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. |
I agree with all that Debarshi said here. I don't think there's much value in 'genericizing' this. It is about giving access to ready-made fedora tools containers, so calling it fedora-toolbox seems obvious and natural. |
fwiw, this is a bit of tangent, but i find the name "toolbox" weird. a toolbox is something you pull tools out of, not something you work inside. I personally wish it was called workbox or something. |
(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. |
Sure, merging the two makes a lot of sense, which is why we reached out earlier to discuss that. If the name is a problem, how about something like "workshop", as the place where you keep your toolboxes and get work done ? |
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.
Yes, just 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! |
Hi,
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. |
thanks @yuqi-zhang ! |
A couple of initial questions:
|
Yes, sure. 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
I have:
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. |
|
i'm surprised you all think |
I have started with the renaming paperwork. With the 0.0.5 release just out and lingering in Fedora's updates-testing repository, this is as good a time as any. This Git repository itself has now been renamed to Next I will rename the various bits and pieces inside the repository - sources, build system, etc.. Then it's matter of rolling a new tarball and going through the Fedora packaging process. |
The "fedora" prefix was used because this project was specifically incubated to make it easier to hack on Fedora Silverblue. That and the mix of upstream technologies (ie., Buildah and Podman) made it uniquely "Fedora". However, over time it has gotten clear that other groups, currently Fedora downstreams like RHEL, are interested in it too. It won't be surprising if in future it transcends the Fedora universe altogether. Moreover, this project was inspired by coreos/toolbox [1]. There are good reasons and enough interest to have a unified toolbox project that addresses the needs of both Fedora CoreOS and Silverblue. Therefore, it is best to drop the "fedora" prefix and call the whole thing just "toolbox". No extra effort was made to retain compatibility with the older name due to the project's young age. Its userbase is limited to the earliest of early adopters, and the benefits of a clean break outweigh the loss of compatibility. The OCI images and the toolbox container still retain the "fedora" prefix to disambiguate them from their counterparts from other operating systems. [1] https://github.com/coreos/toolbox https://github.com/debarshiray/toolbox/issues/8
The contents of this Git repository have been renamed in #52. All that remains is rolling out a new tarball and the downstream packaging. I'd like to wait a bit so that the 0.0.5 release gets a chance to hit the stable updates repositories before rolling the next release. Closing. |
ci: Run on PRs too
Let's discuss overlap with coreos/toolbox@598df78
here.
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
fedora-release
, and there's ageneric-release
.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.
The text was updated successfully, but these errors were encountered: