2:54 p.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZLlA0ACgkQeiVVYja6o6NGGACgjOFv9lUzM2GpJ3GnhqJGXQjs
+rUAoK/8tW/PPOxSc6WZUnBSEq/8ZEol
=ba62
-----END PGP SIGNATURE-----
8:55 a.m.
Hello,
2015-11-17 21:54 GMT+01:00 Stephen Gallagher <sgallagh(a)redhat.com>:
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
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.
9:01 a.m.
Am 18.11.2015 um 15:55 schrieb Miloslav Trmac:
Hello,
2015-11-17 21:54 GMT+01:00 Stephen Gallagher <sgallagh(a)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
9:12 a.m.
2015-11-18 16:01 GMT+01:00 Reindl Harald <h.reindl(a)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
9:23 a.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZMl84ACgkQeiVVYja6o6PWNwCcCRg3o/hp8Yn5DmFCgHPjdInB
7jYAoLEEV4q0uNqXm1lMaOX4nlW3KQe1
=p8sF
-----END PGP SIGNATURE-----
9:28 a.m.
On Wed, Nov 18, 2015 at 10:23 AM, Stephen Gallagher <sgallagh(a)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
9:31 a.m.
-----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(a)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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZMmbAACgkQeiVVYja6o6O3dQCgmgcCsRYDOCMk4eF7nNi3nnH4
47QAn2Au68ULpGGC2UpGohR0aD+JE9Dc
=hVTg
-----END PGP SIGNATURE-----
9:32 a.m.
-----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(a)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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZMmgAACgkQeiVVYja6o6NbFACgmjWUJeMld93LKLHtwA/4lVAK
i4wAoJusBGINVt67xAnLyMzjchT4ftQq
=VXxO
-----END PGP SIGNATURE-----
9:34 a.m.
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
11:39 a.m.
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
11:49 a.m.
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
5:41 p.m.
On Wed, Nov 18, 2015 at 2:55 PM, Miloslav Trmac <mitr(a)redhat.com> wrote:
Hello,
2015-11-17 21:54 GMT+01:00 Stephen Gallagher <sgallagh(a)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
3074
days inactive
3076
days old
server@lists.fedoraproject.org
12 comments
8 participants
participants (8)
-
Andreas Nilsson -
Emmanuel Seyman -
Josh Boyer -
Miloslav Trmač -
Peter Robinson -
Reindl Harald -
Stef Walter -
Stephen Gallagher