On Tuesday, May 3, 2016 11:32:22 AM CDT Kevin Fenzi wrote:
> On Tue, 3 May 2016 11:22:30 -0500
>
> Adam Miller wrote:
> > Collection of RPMs is fine, the goal is just not to ship non-rpm code
> > or content yet outside of Docker-ized application control scripts
> > where needed/applicable.
>
> o
On 4 May 2016 at 21:48, Adam Miller wrote:
> On Tue, May 3, 2016 at 12:32 PM, Kevin Fenzi wrote:
> > On Tue, 3 May 2016 11:22:30 -0500
> > Adam Miller wrote:
> >
> >> Collection of RPMs is fine, the goal is just not to ship non-rpm code
> >> or content yet outside of Docker-ized application con
On Tue, May 3, 2016 at 12:32 PM, Kevin Fenzi wrote:
> On Tue, 3 May 2016 11:22:30 -0500
> Adam Miller wrote:
>
>> Collection of RPMs is fine, the goal is just not to ship non-rpm code
>> or content yet outside of Docker-ized application control scripts
>> where needed/applicable.
>
> ok.
>>
>> It
On Tue, May 3, 2016 at 1:32 PM, Kevin Fenzi wrote:
> On Tue, 3 May 2016 11:22:30 -0500
> Adam Miller wrote:
>
>> Collection of RPMs is fine, the goal is just not to ship non-rpm code
>> or content yet outside of Docker-ized application control scripts
>> where needed/applicable.
>
> ok.
>>
>> It
On Tue, 3 May 2016 11:22:30 -0500
Adam Miller wrote:
> Collection of RPMs is fine, the goal is just not to ship non-rpm code
> or content yet outside of Docker-ized application control scripts
> where needed/applicable.
ok.
>
> It shouldn't but it can in the future, I was more or less replicat
On Mon, May 2, 2016 at 12:07 PM, Kevin Fenzi wrote:
> On Thu, 28 Apr 2016 17:52:44 -0500
> Adam Miller wrote:
>
>> Hello all,
>> We're wrapping up the first phase of the Fedora Docker Layered
>> Image Build Service[0] and the time has come to start thinking about
>> what we as a Project need
On Sun, May 1, 2016 at 10:26 AM, Subhendu Ghosh wrote:
> If we assume that image is immutable, how does one expect the applications
> configuration and data to be managed? Are there additional ENV handlers
> inside the container that might not be present otherwise in the RPM world?
> Is there are
On Thu, 28 Apr 2016 17:52:44 -0500
Adam Miller wrote:
> Hello all,
> We're wrapping up the first phase of the Fedora Docker Layered
> Image Build Service[0] and the time has come to start thinking about
> what we as a Project need to do to formalize what it means to be
> shipping Docker Layer
If we assume that image is immutable, how does one expect the applications
configuration and data to be managed? Are there additional ENV handlers
inside the container that might not be present otherwise in the RPM world?
Is there are requirement for volume mounts for certain locations inside the
c
On Fri, Apr 29, 2016 at 7:55 AM, Colin Walters wrote:
> On Thu, Apr 28, 2016, at 06:52 PM, Adam Miller wrote:
>
>> Docker Layered Image "packaging" Guidelines [1]
>
> This current design means Dockerfiles are always secondary shims.
> I think the most interesting case is for new services which
On Fri, Apr 29, 2016 at 12:59:40PM -0400, Matthew Miller wrote:
> On Thu, Apr 28, 2016 at 05:52:44PM -0500, Adam Miller wrote:
> > Another point to note is that we need to determine how this should be
> > handled
> > in BZ components for bug reporting as well as for filing review requests.
>
> Ma
On Thu, Apr 28, 2016 at 05:52:44PM -0500, Adam Miller wrote:
> Another point to note is that we need to determine how this should be handled
> in BZ components for bug reporting as well as for filing review requests.
Maybe a "Fedora Containers" bugzilla product, so we have a different
namespace fr
On Fri, Apr 29, 2016 at 08:55:02AM -0400, Colin Walters wrote:
> > Docker Layered Image "packaging" Guidelines [1]
> This current design means Dockerfiles are always secondary shims.
> I think the most interesting case is for new services which are
> Docker/container only at least upstream.
On Thu, Apr 28, 2016 at 05:52:44PM -0500, Adam Miller wrote:
> Something else what was brought up when I originally submitted these ideas to
> FESCo[4] (aside from the fact that this should go to devel list first) was
> that it is probably a good idea to establish a Container-centric Guidelines
> C
On Thu, Apr 28, 2016, at 06:52 PM, Adam Miller wrote:
> Docker Layered Image "packaging" Guidelines [1]
This current design means Dockerfiles are always secondary shims.
I think the most interesting case is for new services which are
Docker/container only at least upstream.
Do we e.g. requ
Hopefully we are looking at getting docker-squash/docker-scripts
involved in squashing images
built from the service. At least optionally if not required.
docker-squash should allow you to squash everything in the Dockerfile
back to the from line.
from=$(awk '/^FROM/{print $2}' ~/Dockerfile
Hello all,
We're wrapping up the first phase of the Fedora Docker Layered Image
Build Service[0] and the time has come to start thinking about what we as a
Project need to do to formalize what it means to be shipping Docker Layered
Images once we are capable of building and distributing them.
17 matches
Mail list logo
