PR in: https://pagure.io/fedora-comps/pull-request/248
This came out of various discussions; see https://pagure.io/workstation-ostree-config/pull-request/74 and in particular: https://pagure.io/workstation-ostree-config/pull-request/74#comment-47627
The high level goal here is to make Workstation more container oriented by default, reducing the delta from Atomic.
In particular I'd like to flesh out the "pet/dev container" pattern discussed in various places and encourage people to do that rather than installing things in their root filesystem by default. It's a tremendous change - it was painful for me at first. But there are a lot of compelling advantages.
By having e.g. `podman` (and `docker` for people used to that) installed by default we take a step towards encouraging that by default.
A simple example here: At some point `fpaste` was added to @standard in comps and hence installed on Workstation by default. It's small and harmless, but those types of things pile up. Instead, `fpaste` is exactly the kind of thing that should live in your dev container. Along with several other things from @standard like tcpdump, traceroute, and telnet. And gcc, golang, cargo, ansible, pip, etc.
On Fri, Mar 30, 2018 at 3:39 PM, Colin Walters walters@verbum.org wrote:
PR in: https://pagure.io/fedora-comps/pull-request/248
This came out of various discussions; see https://pagure.io/workstation-ostree-config/pull-request/74 and in particular: https://pagure.io/workstation-ostree-config/pull-request/74#comment-47627
The high level goal here is to make Workstation more container oriented by default, reducing the delta from Atomic.
In particular I'd like to flesh out the "pet/dev container" pattern discussed in various places and encourage people to do that rather than installing things in their root filesystem by default. It's a tremendous change - it was painful for me at first. But there are a lot of compelling advantages.
By having e.g. `podman` (and `docker` for people used to that) installed by default we take a step towards encouraging that by default.
Why include more than one? If it's a new technology to Workstation I think we should choose one and document it well. The problem with having two options is you need to document both and that just gets confusing for the consumer because docs end up with "Do it like X unless you're using Y when do it like"
On Fri, Mar 30, 2018, at 1:24 PM, Peter Robinson wrote:
Why include more than one? If it's a new technology to Workstation I think we should choose one and document it well. The problem with having two options is you need to document both and that just gets confusing for the consumer because docs end up with "Do it like X unless you're using Y when do it like"
podman is relatively new and works fairly well now IME, but there are parts that aren't as mature compared to docker, and it's also fundamentally different in that there's no central daemon; no docker API. There are rather a lot of tools that speak to the docker API, though focus is generally shifting to Kubernetes as the API.
And speaking of that, `oc cluster up` currently depends on Docker, although that limitation will probably be removed at some point.
I understand your point, but those are the reasons why I'd say we currently have everything in the list now.
We've previously been resistant to including developer tools by default because not all developers use the same tools. E.g. gcc is niche and unneeded by web developers, so that one's not present.
But we have not been entirely consistent. E.g. git is installed by default. That one is probably of greater utility, though.
I'm thinking most developers probably have no interest in the containerization tools....
On Fri, Mar 30, 2018 at 9:39 AM, Colin Walters walters@verbum.org wrote:
A simple example here: At some point `fpaste` was added to @standard in comps and hence installed on Workstation by default.
We actually don't include @standard in Workstation precisely to avoid stuff like this getting pulled in. I see that fpaste is indeed installed by default, but that's because it was added directly to @workstation-product.
Michael
On Fri, Mar 30, 2018, at 2:45 PM, mcatanzaro@gnome.org wrote:
I'm thinking most developers probably have no interest in the containerization tools....
Heh. You are definitely living in a separate universe from me!
Now there are a lot of cases of "developer". Picking a representative useful example of say a Scala developer using Eclipse; the "dev container" pattern would probably be hard to adopt vs installing the JVM etc. just on the host. However AFAICS there's lot of tooling to interact with OpenShift/Kube from Eclipse. For example: https://www.eclipse.org/che/docs/6/che/docs/openshift-single-user.html So our including `oc cluster up` helps get OpenShift up locally. It's obviously not hard to install after the fact, but then neither is a lot of other things included in Workstation. The discoverability of non-GUI apps particularly outside of gnome-software is an issue;
Let's go to the opposite end of the spectrum and take a NetworkManager developer. IMO the "dev container" pattern works very well for this. I talked about this here: https://fedorapeople.org/~walters/2018.01-devconf-desktopcontainers/#/7 (See the start for more info, and https://www.youtube.com/watch?v=a4IPWlfkJSo for the recording)
Another argument here is: It doesn't make sense to include gnome-boxes (virt) by default but not containers. (Personally I tend to use vagrant-libvirt a lot for virt cases with which I have a grudgingly-accept/dislike relationship but that's an aside)
On 2018-03-30 21:39, Colin Walters wrote:
It's obviously not hard to install after the fact, but then neither is a lot of other things included in Workstation. The discoverability of non-GUI apps particularly outside of gnome-software is an issue;
Here is what I get in my terminal if I try to type podman on a system where it's not installed: [andreasn@audrey ~]$ podman bash: podman: command not found... Install package 'podman' to provide command 'podman'? [N/y]
So it seems fairly straightforward to discover, provided you know about it. I'm skeptical to the value of providing non-gui apps in the gui software manager. If you're using the CLI, you're already using the CLI. :) Not saying podman doesn't belong in the default install though, I think having the ability to manage containers out of the box makes a lot of sense. - Andreas
On Fri, 2018-03-30 at 10:39 -0400, Colin Walters wrote:
A simple example here: At some point `fpaste` was added to @standard in comps and hence installed on Workstation by default. It's small and harmless, but those types of things pile up.
It's also extremely useful when you are trying to help someone on IRC or a forum thread to know that if you tell them to run fpaste, it will be there, and you won't have to teach them how to install it (via Software or dnf or pet containers or anything else).
On Mon, 2018-04-02 at 08:26 -0700, Adam Williamson wrote:
On Fri, 2018-03-30 at 10:39 -0400, Colin Walters wrote:
A simple example here: At some point `fpaste` was added to @standard in comps and hence installed on Workstation by default. It's small and harmless, but those types of things pile up.
It's also extremely useful when you are trying to help someone on IRC or a forum thread to know that if you tell them to run fpaste, it will be there, and you won't have to teach them how to install it (via Software or dnf or pet containers or anything else).
...though to be fair this is a bit of a derail, as it was just an example. I don't really have a strong opinion either way on the suggestion.
It is a good idea to flesh out the pet/dev container pattern and we'll look into desktop support for this soon.
But it makes sense to me to on include the basic commandline tools for creating and running such containers now, so people can get familiar with them and experiment easily.
I also think the container tools we are talking about here are a bit different from other dev tools like gcc or golang, since the former are needed to put the latter into a container.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Andreas Nilsson -
Colin Walters -
Matthias Clasen -
mcatanzaro＠gnome.org -
Peter Robinson