Ideas from discussion about container-demos HOT 12 OPEN

• Something about modifying Docker so it uses ipfs instead of the layers.
• Permissions. Allowing for +x would let nsinit to start a container directly

from container-demos.

On Fri, Apr 17, 2015 at 03:03:06PM -0700, Ho-Sheng Hsiao wrote:

• Permissions

Permissions are mostly in ipfs/kubo#846, although that issue is
also getting deeper into trust issues that I don't think we need to
resolve yet. We do need at least an executable mode in IPFS if we
want to run #22 directly from a FUSE mount.

Having a statically linked ipfs binary would also be nice 1.
@jbenet just pointed me at https://gobuilder.me/, so I'll see what it
spits out…

from container-demos.

Get performance better so we can demo things without having pre-pinned assets.

from container-demos.

from container-demos.

On Fri, Apr 17, 2015 at 03:41:43PM -0700, Ho-Sheng Hsiao wrote:

Get performance better so we can demo things without having
pre-pinned assets.

Heh, yes ;). And fix whatever reliability issues we were having
around @jbenet's VM :p. Although towards the end I think most of the
issues where that my local IPFS daemon was serving assets over a slow
DSL link.

from container-demos.

from container-demos.

@wking I'm planning on having symlinks. Its on my todo heap

from container-demos.

Let's use checkboxes for tracking todos.

• symlinks (easy)
• permissions on unixfs (metadata?) (easy)
• getting exec to work from ipns inside a container (easy)
• docker storage driver (medium)
• docker with a different image format -- straight ipfs (hard)
• perf issues
• mounting on osx problems?
• prepared built nsinit, etc. (may need multiple archs)

from container-demos.

On Fri, Apr 17, 2015 at 05:39:48PM -0700, Juan Batiz-Benet wrote:

Let's use checkboxes for tracking todos.

I think it's easier (epecially for those of us following by mail, who
don't get updates when comments are updated) to use a separate issue
for each entry in your list, with a "demo" label (allows cross-repo
grouping [1]) or milestone (only inside one repo, but gives %
complete) to group them together.

Mechanics aside, the list looks good to me, except I think “perf
issues” and “docker with a different image format” are pretty fuzzy
;).

I'll ping the libcontainer folks about their build issues.

from container-demos.

On Fri, Apr 17, 2015 at 07:10:26PM -0700, W. Trevor King wrote:

… (allows cross-repo grouping 1)…

Oops, forgot the reference:

from container-demos.

@wking hm-- we use checkboxes a lot in various other repos. They're really useful to capture independent items to ensure are handled without yet having to do the work of making individual issues. Also, sometimes i edit my comments for correctness/clarity if i notice an error within a few min-- will this mess up your flow (happy to avoid it)?

from container-demos.

On Sat, Apr 18, 2015 at 05:06:56AM -0700, Juan Batiz-Benet wrote:

we use checkboxes a lot in various other repos. They're really
useful to capture independent items to ensure are handled without
yet having to do the work of making individual issues.

New issues aren't that hard to make ;). If you like the command
line, you can use ghi 1 and do:

$ ghi open -m 'Support symlinks'

Although I just installed ghi via:

$ gem install ghi
$ ghi config --auth wking

and bumped into 2, which I worked around by adding:

require 'socket'

to the top of my gem-installed
~/.gem/ruby/2.0.0/gems/ghi-0.9.3/lib/ghi/authorization.rb (after the
encoding comment).

Also, sometimes i edit my comments for correctness/clarity if i
notice an error within a few min--

Usually errors that you miss with the first version aren't terribly
serious, so I'm fine missing out on them.

… will this mess up your flow (happy to avoid it)?

If checkboxes are easier for you, I'll handle working with them. But
my personal preference for anything distinct enough for a checkbox is
to open a new issue.

from container-demos.