Hi all,
During today's Cloud Working Group meeting we had a short but spirited discussion on the roles of the Cloud and Server Working Group and the editions we're producing.
I wanted to open a discussion on that topic (see also [1]) ahead of planning for F24 to see if the current setup makes sense, how we can collaborate, and so forth. I have opinions but I want to kick off a discussion without starting from a specific viewpoint.
And... go!
[1] https://fedorahosted.org/cloud/ticket/127
On Wed, Oct 28, 2015 at 2:43 PM, Joe Brockmeier jzb@redhat.com wrote:
Hi all,
During today's Cloud Working Group meeting we had a short but spirited discussion on the roles of the Cloud and Server Working Group and the editions we're producing.
I wanted to open a discussion on that topic (see also [1]) ahead of planning for F24 to see if the current setup makes sense, how we can collaborate, and so forth. I have opinions but I want to kick off a discussion without starting from a specific viewpoint.
Could you provide a bit more context without necessarily offering your suggestions? It's somewhat hard to discuss this without it going everywhere without some kind of background into the overlaps or disparities that you see.
josh
On 10/28/2015 03:03 PM, Josh Boyer wrote:
Could you provide a bit more context without necessarily offering your suggestions? It's somewhat hard to discuss this without it going everywhere without some kind of background into the overlaps or disparities that you see.
I can try to give some context, and yes we probably need some scope. To be clear, this isn't so much disparities/overlaps that *I* see - I just took the AI to start the discussion.
Cloud ticket 127 from roshi opened the discussion about the server WG wanting "to do some coordination with workstation and cloud" and asked for brainstorming. And then discussion followed which I won't try to summarize because I may not do it justice, so please see [1].
Some useful questions, though:
- Does the current set of editions make sense, as produced by the Cloud and Server WG?
- Is the distinction between Cloud and Server wrong?
There's a lot of history here - the Cloud group really started as a place to look at packaging OpenStack, OpenShift, Eucalyptus, CloudStack for Fedora. Then it evolved into cloud images and then a focus on Atomic.
- Should we have a "server" image in the cloud? Is the current suite of editions confusing?
And most importantly - what started the initial initial conversation, how should the Cloud & Server folks work together next release?
[1] https://fedorahosted.org/cloud/ticket/127
On Wed, Oct 28, 2015 at 06:08:13PM -0400, Joe Brockmeier wrote:
There's a lot of history here - the Cloud group really started as a place to look at packaging OpenStack, OpenShift, Eucalyptus, CloudStack for Fedora. Then it evolved into cloud images and then a focus on Atomic.
Actually, I don't think that's true. Take a look at "fr1st p0st":
https://lists.fedoraproject.org/pipermail/cloud/2010-January/000001.html
which says:
There are many potential cloud goals that we could be tackling, but I believe that a lot of people would agree with this proposed initial goal:
LET'S CREATE FEDORA EC2 IMAGES THAT DON'T SUCK.
(Although we did go to talking about packaging Eucalyptus by the next month.)
On 10/28/2015 07:42 PM, Matthew Miller wrote:
Actually, I don't think that's true. Take a look at "fr1st p0st":
https://lists.fedoraproject.org/pipermail/cloud/2010-January/000001.html
I stand, well sit, corrected. I was going off memory and wading through the original wiki materials, which ISTR were largely IaaS/PaaS focused.
Thanks!
jzb
On Wed, Oct 28, 2015 at 6:08 PM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 03:03 PM, Josh Boyer wrote:
Could you provide a bit more context without necessarily offering your suggestions? It's somewhat hard to discuss this without it going everywhere without some kind of background into the overlaps or disparities that you see.
I can try to give some context, and yes we probably need some scope. To be clear, this isn't so much disparities/overlaps that *I* see - I just took the AI to start the discussion.
Cloud ticket 127 from roshi opened the discussion about the server WG wanting "to do some coordination with workstation and cloud" and asked for brainstorming. And then discussion followed which I won't try to summarize because I may not do it justice, so please see [1].
Read, thanks for the pointer.
Some useful questions, though:
- Does the current set of editions make sense, as produced by the Cloud
and Server WG?
Well, confusing on "what is the Cloud base image for" aside, I think the editions as produced make sense.
- Is the distinction between Cloud and Server wrong?
There's a lot of history here - the Cloud group really started as a place to look at packaging OpenStack, OpenShift, Eucalyptus, CloudStack for Fedora. Then it evolved into cloud images and then a focus on Atomic.
IMO, no it isn't wrong.
- Should we have a "server" image in the cloud? Is the current suite of
editions confusing?
I don't think it's confusing, but I also don't think having a server image in the cloud is a bad idea.
And most importantly - what started the initial initial conversation, how should the Cloud & Server folks work together next release?
Given that I only have tangential interest in either WG, this suggestion might not make sense. However, I see Server and Cloud as two separate but complimentary things. The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
So assuming we don't have one image for both, I think they can still work together more closely. I like the idea in the ticket of having a cloudtoserver script. I also like the idea of a server to cloud script that could convert a Server install into a Cloud image. If we were to take into account that an admin might want to provision a Server in a VM or on a bare metal machine and then say "take this and make it a cloud image" with said script, that might work well too. The Server image is easier for a human to use by far, and cloudify-ing a Server install into a deployable cloud image might result in a larger cloud image but some people won't care.
Anyway, the gist of my ramblings is that I think the two groups could compliment each other better but I still view them as separate Editions with separate (but possibly overlapping) audiences. My ramblings my be wrong, but they make sense in my head.
josh
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get our image adopted with something else. - lack of a great alternative.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
[1] https://github.com/tmrts/flamingo
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
I completely believe both of these.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
I'm not sure what "rich boot process" means. I'd immediately interpret that as "a real init process" which to me means using systemd. Somehow I don't think that's what you're thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
On Thu, Oct 29, 2015 at 8:30 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
I completely believe both of these.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
I'm not sure what "rich boot process" means. I'd immediately interpret that as "a real init process" which to me means using systemd. Somehow I don't think that's what you're thinking... :)
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
-Mike
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
On 10/29/2015 09:33 AM, Michael McGrath wrote:
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
What's the state of this at the moment?
On Thu, Oct 29, 2015 at 8:36 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/29/2015 09:33 AM, Michael McGrath wrote:
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
What's the state of this at the moment?
Joe Brockmeier | Community Team, OSAS jzb@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
We're doing planning now for our next atomic deliverable, I'm advocating for it gets pulled into that.
On Thu, Oct 29, 2015 at 8:33 AM, Michael McGrath mmcgrath@redhat.com wrote:
On Thu, Oct 29, 2015 at 8:30 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment.
Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic.
(It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.)
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
I completely believe both of these.
Mike has talked about a "rich boot process" previously, and I wonder if we're ready to start working on that?
I'm not sure what "rich boot process" means. I'd immediately interpret that as "a real init process" which to me means using systemd. Somehow I don't think that's what you're thinking... :)
If you hate cloud-init, then you'll love rich boot. Which is essentially a handoff at boot time from cloud-init to Ansible for further configuration.
+1
Sounds great, looking forward to more information on the topic.
-AdamM
-MikeAlso, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
-- Mike McGrath | mmcgrath@redhat.com | (312) 660-3547 Atomic | Red Hat Chicago | http://projectatomic.io/ _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Oct 29, 2015 9:30 AM, "Josh Boyer" jwboyer@fedoraproject.org wrote:
thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
On Thu, Oct 29, 2015 at 9:47 AM, Subhendu Ghosh sghosh151@gmail.com wrote:
On Oct 29, 2015 9:30 AM, "Josh Boyer" jwboyer@fedoraproject.org wrote:
thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
josh
On Oct 29, 2015 9:30 AM, "Josh Boyer" jwboyer@fedoraproject.org wrote:
thinking... :)
Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight contextualization tool that aims to handle initialization of cloud instances." [1] Maybe this is something we could look at for F24? CC'ing Tamer Tas, the student who worked on that. (It's targeted at being a cloud-init replacement for Atomic, so...)
That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure.
josh
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
At least mattdm knew of it because he mentioned it to me once when I was beating my head against the wall with it.
Peter
On Fri, Oct 30, 2015 at 11:20:36AM +0000, Peter Robinson wrote:
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
At least mattdm knew of it because he mentioned it to me once when I was beating my head against the wall with it.
Yeah, there's some discussion here: https://fedorahosted.org/cloud/ticket/23
On Fri, Oct 30, 2015 at 9:06 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Oct 30, 2015 at 11:20:36AM +0000, Peter Robinson wrote:
CoreOS has built cloud-config as a Go implementation of cloud-init to get around the python problem.
Did they tell anyone they were doing that? I'm curious if we have two groups that could be working together here that are now duplicating effort simply because of lack of communication.
At least mattdm knew of it because he mentioned it to me once when I was beating my head against the wall with it.
Yeah, there's some discussion here: https://fedorahosted.org/cloud/ticket/23
Ah, cool. Thanks. Also, in my earlier reply I had misread "CoreOS" as "CentOS". It would have been even more disappointing if we weren't collaborating with CentOS than CoreOS. In the end, people seem to be aware of things anyway. Yay and stuff.
josh
On Thu, Oct 29, 2015 at 1:16 PM, Joe Brockmeier jzb@redhat.com wrote:
On 10/28/2015 08:21 PM, Josh Boyer wrote:
The *could* be the same thing, except cloud-init is terrible and I hate it and if that was the single offering we had for some kind of C&S WG I would cry. I hate it because it is ridiculous to use in a non-cloud environment, and Server very much has that as part of it's reach.
Forking this thread briefly because I think this deserves its own discussion.
Is your objection primarily to the concept of cloud-init or the implementation? If it's the concept, not much we can help with there. If it's the implementation...
We've talked about replacing cloud-init a few times in the past, but there are two objections:
- cloud-init is "standard" and we have an uphill marketing battle to get
our image adopted with something else.
- lack of a great alternative.
This is one of the utilities I've often thought it would be great for the systemd group of utilities to absorb as it crosses over into a bunch of that space like setting hostnames, auth etc. I believe they'd likely do it some justice.
Peter
----- Original Message -----
From: "Joe Brockmeier" jzb@redhat.com To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org, server@lists.fedoraproject.org Sent: Wednesday, October 28, 2015 11:43:27 AM Subject: [DISCUSS] Cloud and Server Workgroup relationship
Hi all,
During today's Cloud Working Group meeting we had a short but spirited discussion on the roles of the Cloud and Server Working Group and the editions we're producing.
I wanted to open a discussion on that topic (see also [1]) ahead of planning for F24 to see if the current setup makes sense, how we can collaborate, and so forth. I have opinions but I want to kick off a discussion without starting from a specific viewpoint.
And... go!
My two cents: I'm looking at Fedora's editions with certain expectations. I see Workstation, and I know what I'm going to get and where I expect it to run. I see Server, and I expect:
* a fairly minimal image * something I can run on bare metal, VM or cloud
Instead, Server is a big image (2.1GB) that's not supposed to be run in the cloud.
Or, I assume I can rough something out w/ vagrant in VMs, and then deploy that on metal, but in Fedora, those are different variants, and things like LVM vs. no LVM (if I recall correctly) come into play, and there's no vagrant box for Fedora Server, because that's a cloud thing (I guess??). A no-cloud rule for Fedora Server feels antiquated and weird to me.
It's not the end of the world that my expected Fedora Server edition is in reality split into two separate editions, Server and Cloud, but I've seen it mentioned that Cloud Edition adoption has been slow -- it might be more findable for people if it's presented with or somehow integrated with the Server Edition.
Finally, I think that the movement of Fedora Atomic has been a bit slow, and I've witnessed the confusion of having cloud-base and atomic smushed together (in mtgs & such). If running well in cloud environments was part of the Server WG charter, and atomic was the focus in the Cloud WG, that'd be a cleaner arrangement. But, maybe this just means that atomic needs its own SIG (or WG -- I'm not 100% clear on the difference).
Of course, just because some might expect the Editions to work a certain way doesn't mean that this is the right way to do it, and I know that many things went into the definition of the WGs the way there are.
Regards, Jason
[1] https://fedorahosted.org/cloud/ticket/127
Joe Brockmeier | Community Team, OSAS jzb@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
On 11/03/2015 02:44 PM, Jason Brooks wrote:
My two cents: I'm looking at Fedora's editions with certain expectations. I see Workstation, and I know what I'm going to get and where I expect it to run. I see Server, and I expect:
- a fairly minimal image
- something I can run on bare metal, VM or cloud
Instead, Server is a big image (2.1GB) that's not supposed to be run in the cloud.
Just to add a clarification, the DVD is in fact 2.1GB. An installed server, however, lives very well on minimal resources.
A default Fedora Server install installs 603 packages in Anaconda. With the "Minimal" package set selected in anaconda, only 270 packages are installed.
I have run a FreeIPA server on a Fedora Server VM with 1024MB of RAM, and a 4GB hard drive. Granted, the use case was minimal - 30 or so users, and a few systems actually enrolled in the domain - but I had zero issues with resources on that system.
Some snippets from two freshly installed systems, the first a 'minimal' install from the Fedora Server DVD:
[root@localhost ~]# df -lh Filesystem Size Used Avail Use% Mounted on devtmpfs 993M 0 993M 0% /dev tmpfs 1001M 0 1001M 0% /dev/shm tmpfs 1001M 412K 1001M 1% /run tmpfs 1001M 0 1001M 0% /sys/fs/cgroup /dev/mapper/fedora-root 3.1G 749M 2.4G 24% / tmpfs 1001M 4.0K 1001M 1% /tmp /dev/vda1 477M 79M 369M 18% /boot tmpfs 201M 0 201M 0% /run/user/0 [root@localhost ~]# dnf list installed | wc -l 272 [root@localhost ~]# dnf list installed | fpaste -bash: fpaste: command not found [root@localhost ~]# free -m total used free shared buff/cache available Mem: 2001 80 1645 0 274 1876 Swap: 411 0 411 [root@localhost ~]#
And from the Fedora Server install:
[root@localhost ~]# df -lh Filesystem Size Used Avail Use% Mounted on devtmpfs 991M 0 991M 0% /dev tmpfs 1001M 0 1001M 0% /dev/shm tmpfs 1001M 464K 1001M 1% /run tmpfs 1001M 0 1001M 0% /sys/fs/cgroup /dev/mapper/fedora-root 3.1G 1.2G 2.0G 37% / tmpfs 1001M 4.0K 1001M 1% /tmp /dev/vda1 477M 96M 352M 22% /boot tmpfs 201M 0 201M 0% /run/user/0 [root@localhost ~]# dnf list installed | wc -l 605 [root@localhost ~]# dnf list installed | fpaste Uploading (50.4KiB)... WARNING: Could not shorten URL http://paste.fedoraproject.org/290874/63302514 [root@localhost ~]# free -m total used free shared buff/cache available Mem: 2001 96 1532 0 372 1858 Swap: 411 0 411 [root@localhost ~]#
server@lists.fedoraproject.org
-
Adam Miller -
Dan Mossor -
Jason Brooks -
Joe Brockmeier -
Josh Boyer -
Matthew Miller -
Mike McGrath -
Peter Robinson -
Subhendu Ghosh