container-demos icon indicating copy to clipboard operation
container-demos copied to clipboard

Ideas from discussion

Open jbenet opened this issue 11 years ago • 12 comments

jbenet avatar Apr 17 '15 22:04 jbenet

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

hosh avatar Apr 17 '15 22:04 hosh

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

  • Permissions

Permissions are mostly in ipfs/go-ipfs#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…

wking avatar Apr 17 '15 22:04 wking

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

hosh avatar Apr 17 '15 22:04 hosh

Longer term down the nsinit path, it would be good to be able to use Docker's bridging with nsinit. I'm not sure how that's handled in Docker, but the default nsinit config just sets up the loopback interface. If it's another stand-alone-ish library like libcontainer, it could be pretty easy to recycle here. If it's baked into docker/docker, it will likely be harder to tease out.

wking avatar Apr 17 '15 22:04 wking

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.

wking avatar Apr 17 '15 22:04 wking

And symlink-support would be nice, it's a pain (for me anyway) to get a statically linked ipfs, and Linux distros like to use symlinks like:

libc.so.6 -> libc-2.20.so

It's not hard to unwind those links, but it is an extra step if you're going from a vanilla distro tarball to something you can store in IPFS.

wking avatar Apr 18 '15 00:04 wking

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

whyrusleeping avatar Apr 18 '15 00:04 whyrusleeping

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)

jbenet avatar Apr 18 '15 00:04 jbenet

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.

wking avatar Apr 18 '15 02:04 wking

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

… (allows cross-repo grouping 1)…

Oops, forgot the reference:

wking avatar Apr 18 '15 02:04 wking

@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)?

jbenet avatar Apr 18 '15 12:04 jbenet

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.

wking avatar Apr 18 '15 15:04 wking