-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Similar to my thread about the @server-hardware-support group, the @container-management group also takes up a good chunk of space (38MB above the minimal install) in the default Server install, as well as including an additional available-by-default service.
Originally, we included Docker for its popularity and because Cockpit and rolekit each had some support for operating with it. In F23 and onwards, rolekit is capable of automatically-installing docker if it is required to support a role, so having it installed by default is no longer critical from that perspective.
This leaves Cockpit: one of Cockpit's more popular features is the ability to manage Docker images and containers from the UI. Cockpit has the ability to start Docker on the system if it's installed but not running. I'd like to recommend that Cockpit also grow the capability to install Docker if an administrator wants to use that portion of the UI. This way, we can avoid installing it by default and just deploy it automatically once an Administrator is interested in using it.
As a side-note, I think this is a policy we should consider following throughout Server: try to do lazy package installation whenever possible. Much of our philosophy in rolekit, Cockpit and realmd is around installing what we need only when we need it and an administrator has made a clear decision to use it. We should try to make that a consistent policy.
Hello, 2015-11-17 21:54 GMT+01:00 Stephen Gallagher sgallagh@redhat.com:
Similar to my thread about the @server-hardware-support group, the @container-management group also takes up a good chunk of space (38MB above the minimal install) in the default Server install, as well as including an additional available-by-default service.
Originally, we included Docker for its popularity and because Cockpit and rolekit each had some support for operating with it. In F23 and onwards, rolekit is capable of automatically-installing docker if it is required to support a role, so having it installed by default is no longer critical from that perspective.
This leaves Cockpit: one of Cockpit's more popular features is the ability to manage Docker images and containers from the UI.
<snip>
As a side-note, I think this is a policy we should consider following throughout Server: try to do lazy package installation whenever
possible.
So I am vaguely worried about this trend. Should image size really the #1 priority?
Functionality added by default, and especially as mandatory, on top of minimal install (whatever minimal install is this year), is not just useful the way a new feature is useful in an appliance; it is also (and IMO primarily) useful as making the “platform” more valuable because application writers can depend on the feature being always available, and users can expect the applications to be more easily deployed.
Docker is a good example: its users are not rolekit and Cockpit, its users are all the Dockerized applications out there; and* if* Docker succeeds as an application delivery mechanism, its value to all the other applications will be much larger than the value of making rolekit and Cockpit a bit easier to deploy.
You’re right, we can reasonably modify Cockpit or other applications we package, for not having Docker available; but we may not be able to modify all the other applications out there. Or perhaps we can officially decide e.g. that the way to deploy Docker containers is to run something like (atomic install), and have (atomic install) deal with automatically installing Docker.
Now, perhaps Docker should not be a part of the Fedora Server platform, not yet, or not ever. I don’t know, and I could easily accept an argument that it should not be there. It just worries me that the conversation is in terms of feature vs. storage, without talking about the platform at all. Mirek
Am 18.11.2015 um 15:55 schrieb Miloslav Trmac:
Hello, 2015-11-17 21:54 GMT+01:00 Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com>:
Similar to my thread about the @server-hardware-support group, the @container-management group also takes up a good chunk of space (38MB above the minimal install) in the default Server install, as well as including an additional available-by-default service. Originally, we included Docker for its popularity and because Cockpit and rolekit each had some support for operating with it. In F23 and onwards, rolekit is capable of automatically-installing docker if it is required to support a role, so having it installed by default is no longer critical from that perspective. This leaves Cockpit: one of Cockpit's more popular features is the ability to manage Docker images and containers from the UI.<snip>
As a side-note, I think this is a policy we should consider following throughout Server: try to do lazy package installation whenever possible.So I am vaguely worried about this trend. Should image size really the #1 priority?
yes in case of a default setup
Functionality added by default, and especially as mandatory, on top of minimal install (whatever minimal install is this year), is not just useful the way a new feature is useful in an appliance; it is also (and IMO primarily) useful as making the “platform” more valuable because application writers can depend on the feature being always available, and users can expect the applications to be more easily deployed.
where do you draw the line?
if you have 100, 200, 300 server instances size matters and if you open the candle of worms "what *could* be useful" you end in fat default installs to satisfy anybody
it's way easier to install something you need then get rid of things you don't know why they are there from the start
Docker is a good example: its users are not rolekit and Cockpit, its users are all the Dockerized applications out there; and/if/ Docker succeeds as an application delivery mechanism, its value to all the other applications will be much larger than the value of making rolekit and Cockpit a bit easier to deploy
no docker is a bad example, we are running Fedora servers from 2008 on for everything virtualized, long before "cloud" and "docker" and while you can indeed run docker inside a virtual machine none of them do and will in the near future
2015-11-18 16:01 GMT+01:00 Reindl Harald h.reindl@thelounge.net:
Am 18.11.2015 um 15:55 schrieb Miloslav Trmac:
Functionality added by default, and especially as mandatory, on top of minimal install (whatever minimal install is this year), is not just useful the way a new feature is useful in an appliance; it is also (and IMO primarily) useful as making the “platform” more valuable because application writers can depend on the feature being always available, and users can expect the applications to be more easily deployed.
where do you draw the line?
if you have 100, 200, 300 server instances size matters and if you open the candle of worms "what *could* be useful" you end in fat default installs to satisfy anybody
No, certainly not add everything somebody thinks *could* be useful; what I’m saying is that the mandatory APIs *define* the product from the point of view of application developers; so we definitely need to be careful about what we want the product to be, and what APIs we can long-term support at all; but if we have no always-available APIs, then, for application developers, *we have no product*.
… OTOH now I have realized that perhaps we *do* want all the APIs to be in Fedora Base/minimal, and the Server to only add the servers/applications/appliance-like features. So I might have been completely wrong about this. Mirek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2015 10:01 AM, Reindl Harald wrote:
no docker is a bad example, we are running Fedora servers from 2008 on for everything virtualized, long before "cloud" and "docker" and while you can indeed run docker inside a virtual machine none of them do and will in the near future
I find this to be a really head-scratching statement. Nearly every instance of a docker host that I have ever encountered in the real world is running on a virtual machine. The overwhelming majority are living in Amazon EC2 or OpenStack deployments. Yes, there are cases where people are installing Project Atomic or CoreOS on bare metal, but it's far more common to see this happening in a cloud environment.
On Wed, Nov 18, 2015 at 10:23 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2015 10:01 AM, Reindl Harald wrote:
no docker is a bad example, we are running Fedora servers from 2008 on for everything virtualized, long before "cloud" and "docker" and while you can indeed run docker inside a virtual machine none of them do and will in the near future
I find this to be a really head-scratching statement. Nearly every instance of a docker host that I have ever encountered in the real world is running on a virtual machine. The overwhelming majority are living in Amazon EC2 or OpenStack deployments. Yes, there are cases where people are installing Project Atomic or CoreOS on bare metal, but it's far more common to see this happening in a cloud environment.
The quoted usecase is not the common usecase. We don't create products tailored to custom setups created 7 years go. We create them for where things are heading.
josh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2015 10:28 AM, Josh Boyer wrote:
On Wed, Nov 18, 2015 at 10:23 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2015 10:01 AM, Reindl Harald wrote:
no docker is a bad example, we are running Fedora servers from 2008 on for everything virtualized, long before "cloud" and "docker" and while you can indeed run docker inside a virtual machine none of them do and will in the near future
I find this to be a really head-scratching statement. Nearly every instance of a docker host that I have ever encountered in the real world is running on a virtual machine. The overwhelming majority are living in Amazon EC2 or OpenStack deployments. Yes, there are cases where people are installing Project Atomic or CoreOS on bare metal, but it's far more common to see this happening in a cloud environment.
The quoted usecase is not the common usecase. We don't create products tailored to custom setups created 7 years go. We create them for where things are heading.
Sorry Josh, I can't parse that. What is the "quoted usecase" here?
Am 18.11.2015 um 16:23 schrieb Stephen Gallagher:
On 11/18/2015 10:01 AM, Reindl Harald wrote:
no docker is a bad example, we are running Fedora servers from 2008 on for everything virtualized, long before "cloud" and "docker" and while you can indeed run docker inside a virtual machine none of them do and will in the near future
I find this to be a really head-scratching statement. Nearly every instance of a docker host that I have ever encountered in the real world is running on a virtual machine
that may be true, but not every virtual fedora instance is running docker - that was my point :-)
frankly these days nobody installs anything non-vortualized expectt the virtualization host itself when it comes to servers, but that don't bring docker in the mix everywhere
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2015 09:55 AM, Miloslav Trmac wrote:
Hello, 2015-11-17 21:54 GMT+01:00 Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com>:
Similar to my thread about the @server-hardware-support group, the @container-management group also takes up a good chunk of space (38MB above the minimal install) in the default Server install, as well as including an additional available-by-default service.
Originally, we included Docker for its popularity and because Cockpit and rolekit each had some support for operating with it. In F23 and onwards, rolekit is capable of automatically-installing docker if it is required to support a role, so having it installed by default is no longer critical from that perspective.
This leaves Cockpit: one of Cockpit's more popular features is the ability to manage Docker images and containers from the UI.
<snip>
As a side-note, I think this is a policy we should consider following throughout Server: try to do lazy package installation whenever
possible.
So I am vaguely worried about this trend. Should image size really the #1 priority?
In the case of Docker, I'm less concerned about the image size (though it's non-trivial) and more concerned about the presence of an additional always-on service. It *is* a potential security risk (particularly since Docker is effectively a potential privilege-escalation path).
Functionality added by default, and especially as mandatory, on top of minimal install (whatever minimal install is this year), is not just useful the way a new feature is useful in an appliance; it is also (and IMO primarily) useful as making the “platform” more valuable because application writers can depend on the feature being always available, and users can expect the applications to be more easily deployed.
Right, so really this thread is about whether we want to treat Docker as "API" for Fedora Server. We have been doing this so far, but it's reasonable to reopen the conversation, particularly in terms of feedback from users that they dislike having this be a non-optional component of Server. Add that to the fact that Fedora and Red Hat's strategy for Docker and containers has been mostly focused on Project Atomic and I would say there's an argument to be made that Docker is not an obvious necessity for Fedora Server.
Docker is a good example: its users are not rolekit and Cockpit, its users are all the Dockerized applications out there; and/if/ Docker succeeds as an application delivery mechanism, its value to all the other applications will be much larger than the value of making rolekit and Cockpit a bit easier to deploy.
I think you got this backwards. Cockpit and rolekit are consumers of Docker; they make it easier to deploy docker containers.
You’re right, we can reasonably modify Cockpit or other applications we package, for not having Docker available; but we may not be able to modify all the other applications out there. Or perhaps we can officially decide e.g. that the way to deploy Docker containers is to run something like (atomic install), and have (atomic install) deal with automatically installing Docker.
Or we can simply make the @container-management group an optional install for the Server media, such that users who want it can opt-in and everyone else can skip it. Or we could try to find a way to do the reverse: allow people to opt-out of it.
Today, it's a hard dependency because we A) install the @container-management group by default and B) the `cockpit` metapackage includes `cockpit-docker` which pulls in `docker` as a dependency.
Now, perhaps Docker should not be a part of the Fedora Server platform, not yet, or not ever. I don’t know, and I could easily accept an argument that it should not be there. It just worries me that the conversation is in terms of feature vs. storage, without talking about the platform at all.
Right, I think that's the real purpose of this thread. Not to solve the general case but to decide whether Docker in specific is something we want to consider a core API of Fedora Server. If it is, then we need to communicate that better.
On 18.11.2015 16:31, Stephen Gallagher wrote:
On 11/18/2015 09:55 AM, Miloslav Trmac wrote:
<snip>
Docker is a good example: its users are not rolekit and Cockpit, its users are all the Dockerized applications out there; and/if/ Docker succeeds as an application delivery mechanism, its value to all the other applications will be much larger than the value of making rolekit and Cockpit a bit easier to deploy.
I think you got this backwards. Cockpit and rolekit are consumers of Docker; they make it easier to deploy docker containers.
I think that Mitr got this right. Cockpit is not a consumer of Docker. If Docker is installed then Cockpit provides a UI for Docker, that's it.
The consumer of Docker is the user wishing to run a container.
Stef
On Wed, Nov 18, 2015 at 2:55 PM, Miloslav Trmac mitr@redhat.com wrote:
Hello, 2015-11-17 21:54 GMT+01:00 Stephen Gallagher sgallagh@redhat.com:
Similar to my thread about the @server-hardware-support group, the @container-management group also takes up a good chunk of space (38MB above the minimal install) in the default Server install, as well as including an additional available-by-default service.
Originally, we included Docker for its popularity and because Cockpit and rolekit each had some support for operating with it. In F23 and onwards, rolekit is capable of automatically-installing docker if it is required to support a role, so having it installed by default is no longer critical from that perspective.
This leaves Cockpit: one of Cockpit's more popular features is the ability to manage Docker images and containers from the UI.
<snip> > > As a side-note, I think this is a policy we should consider following > throughout Server: try to do lazy package installation whenever > > possible.
So I am vaguely worried about this trend. Should image size really the #1 priority?
I don't see that as just about size but as much about security. In banking/finance/govt/numerous other industries if it's not needed it's not installed. Also things like bandwidth for updates, and something like docker is fairly regularly updated ends up being a reasonable amount of churn for no benefit to the user. A lot of places around the world still have limited bandwidth.
Peter
On 11/17/2015 09:54 PM, Stephen Gallagher wrote:
This leaves Cockpit: one of Cockpit's more popular features is the ability to manage Docker images and containers from the UI. Cockpit has the ability to start Docker on the system if it's installed but not running. I'd like to recommend that Cockpit also grow the capability to install Docker if an administrator wants to use that portion of the UI. This way, we can avoid installing it by default and just deploy it automatically once an Administrator is interested in using it.
One concern I have is that once docker is installed from Cockpit, there is no way to remove it from Cockpit, so it becomes an irreversible action. We do start services on demand, but those can be stopped and disabled again elsewhere in the UI. - Andreas
server@lists.fedoraproject.org
-
Andreas Nilsson -
Emmanuel Seyman -
Josh Boyer -
Miloslav Trmač -
Peter Robinson -
Reindl Harald -
Stef Walter -
Stephen Gallagher