-
Notifications
You must be signed in to change notification settings - Fork 147
Spec first read feedback #12
Comments
From @tnachen on December 2, 2014 4:43 Hi Tim, can you link a reference about what lmctfy isolators architecture is like? |
From @thockin on December 2, 2014 4:47 https://github.com/google/lmctfy https://github.com/google/lmctfy/blob/master/include/lmctfy.proto On Mon, Dec 1, 2014 at 8:43 PM, Timothy Chen notifications@github.com
|
From @markllama on December 2, 2014 14:39 I'm seriously for keeping current terminology: Keep "container" being a single set of namespaces and context in which to run processes. Another term for a set of these. |
From @bobrik on December 2, 2014 14:41 +1 for keeping container as a set of namespaces. |
From @thockin on December 2, 2014 15:36 The naming problem as I see it is this: if you define container as a set of Within Google (for full disclosure, of course) we make heavy use of The difference is that we have semantic differences between our two-level I guess I am arguing for some principled definition of container and what
It feels to me like the outer container is really ONLY a list of apps to On Tue, Dec 2, 2014 at 6:41 AM, Ian Babrou notifications@github.com wrote:
|
From @markllama on December 2, 2014 16:8 Do you call directories something different because they can contain subdirectories? |
From @bketelsen on December 2, 2014 16:33 so glad to see the k8s team here 👍 |
From @timothysc on December 2, 2014 17:53 define a different word for a set of containers
Files in an images must maintain all of their original properties, can this include capabilities?
However, there are things that (currently) are hard to do without any daemon - an example we run up against is prioritized OOM handling.
+1 re: extraction. |
From @thockin on December 2, 2014 19:10 No, I would not call a directory something different because a directory IS But you don't call a tarfile a directory, even though it can hold
|
From @thockin on December 2, 2014 19:15 Re resource manager's job: I agree, but there is a lot of overlap between
|
From @rektide on December 2, 2014 21:3
Disk usage is more important to me, but we're both going to be hugely impacted by this. I'd specifically call out Revsiting How We Put Together Linux Systems as the ideal I'd like to see well supported in Rocket: each system points-to/shares a read only /usr system image, a read-only /etc configuration state, and perhaps some read-only /opt/foo apps, and has it's own r/w /var mounted up to make a system. The repository of "images" becomes nothing more than a bunch of different /usr trees in this scenario, which is ideal for disk usage, and disk-io/fs-caching. All the above goes to +1:
|
From @markllama on December 2, 2014 21:12 Directory is not inherently recursive, it's defined as recursive. There's no reason a container couldn't contain a sub-container (so long as the nesting is proper in the mathematical sense) either metaphorically or technically. There may be other reasons to use a different term, but that isn't one. |
From @thockin on December 2, 2014 21:50 Sorry, I don't follow. A directory is recursive in that every operation supported on dir A/ is Will the runtime environment support arbitrarily nested containers? Can I On Tue, Dec 2, 2014 at 1:12 PM, Mark Lamourine notifications@github.com
|
From @markllama on December 2, 2014 23:41 Ok we're mixing metaphors and technical definitions. The metaphor of a directory (phone book) is not recursive. (folder is, but that's not the term we use) The metaphor of a container is recursive. Containers can contain other containers The technical definition of a container within the software space is, as yet, undefined, that's what we're discussing. You commented that google uses sub-containers. So great. Let a container be the definition of a view which a process will see as defined by the kernel namespaces and other contextual settings. So there's still no reason that a container could be defined in terms of another container (a sub-container). It's not the current convention but it makes more sense to me than "app contaiiner" as opposed to some other kind of container. "app container" has it's own problems in that it implies a definition of an "app" which is to be contained, but is not yet defined. |
From @jonboulle on December 2, 2014 23:44 just to touch on a couple of @thockin's original points:
These are bugs/inconsistencies in the text of the spec; "version" is a fully separate entity from the name, and essentially just another label like arch and os, so it should no longer be embedded in the string. I'm cleaning up the spec now to reflect this. |
From @jonboulle on December 3, 2014 2:56 Have done what I mentioned in rkt/rkt#151 (comment) and split out version as a first-class citizen in the app manifest along with {name, os, arch}.
Cleared this up in the spec. |
Hey Tim- On Mon, Dec 1, 2014 at 6:25 PM, Tim Hockin notifications@github.com wrote:
Thanks for the detailed feedback. I am going to reply-inline and also
We talked this over a ton with different folks while working on the
Essentially we want a name for a container that isn't a lightweight VM
The "extracts copy" behavior is only for people with systems that
What other signals should be sent to a UNIX process as it shuts down?
Hrm, am I about to be disappointed that tar doesn't encode capabilities?
I am confused on what you are getting at here. Are you thinking about
I agree we need to consider these things. Are you talking about re-prioritizing the OOM based on runtime
Acknowledged, I have some outstanding things that didn't make it into
Sorry, this is a leftover from an early name bike-shedding. I will fix it up.
ABSOLUTELY! I would love to have help on the schemas and names here.
Again, a stupid thing we didn't fix before release. Fixed here:
I would like to not provide them by default but have a way for an app
This is just a weak argument that should be deleted. The primary
Fixed as I mentioned above. We will make os, arch and version labels
How would we support string user and group names?
What are you referring to here in particular? I completely agree about Thanks again! Brandon |
From @thockin on December 4, 2014 6:2 I don't know where phone book came from - "directory" for this conversation If a container can contain containers, then this spec should not Now to speak out the other side of my mouth. Allowing arbitrary nesting in Tim On Tue, Dec 2, 2014 at 3:41 PM, Mark Lamourine notifications@github.com
|
On Tue, Dec 2, 2014 at 7:05 PM, Brandon Philips
LOL - this is a great name.
What's wrong with simply qualifying them both, if they are really Or adopt kubernetes names and run with pod & container?
I'd like to see the spec describe it more generically, then.
HTTP get. Exec. Just to name a few.
probably :(
Adding args (or redefining them entirely) is one facet. But also
What I meant is this. Consider two containers. Container P is a prod But this is hard to do without some agent in userspace. We might be This goes a bit to the idea of layers and guarantees. The bottom-most
I'll have to re-re-read this spec, won't I? :)
I think that you need to think hard about not being LSB-ish. Like it Ditto for /proc and /sys anbd /dev/shm and /dev/pts and (.....) -
I'm not sure on this one. If you assume that the environment has a
The first part was the isolator flag for "private network" - why? The
|
From @hwinkel on December 4, 2014 10:47
Thats true, however what about defining WHAT a containerized application really needs In our experiences import in OVA Images into a Supervisor works like this, the OVA just my toughs. |
I am pretty confident that almost everything raised here has been addressed in the spec, with the following exceptions still open for discussion:
|
From @thockin on December 2, 2014 2:25
Collected notes as I read through. Sorry for the length. If any of these become worth discussing, we can fork to different topics.
This changes the established naming from what Docker calls a container to what Kubernetes calls a pod. I think that changing the meaning of "container" at this point might be detrimental to the overall comprehension of the system. I would propose to keep container to mean what you call app-container and define a different word for a set of containers.
Example use case talks about "puts them into its local on-disk cache" and "extracts two copies". This sets off immediate alarm bells for me - disk IO is the single most contended resource, in our experience. To be successful, this spec really must be implementable with a minimum of disk IO. For example, I should be able to mount a pre-built cache of images and satisfy container run requests. That's not to say that disk IO can not satisfy the spec, but it must not be a requirement.
SIGTERM should be just one kind of termination signal
Files in an images "must maintain all of their original properties" - can this include capabilities?
One thing Docker does well is differentiate WHAT to run from HOW to run it. Does this address that idea? There's some overlap in lifecycle stuff, but some other things like resources are clearly dependent on how a container will be used. How about command line flags? Being able to take a pre-built container, such as ubuntu, and run things in it without creating and pushing a new container is powerful.
That rkt is not a daemon is very similar to what we were pushing with lmctfy. However, there are things that (currently) are hard to do without any daemon - an example we run up against is prioritized OOM handling. This spec should carefully consider the strata of the overall system and how some things cross between them.
Volumes are under-specified. Can I mount them at different places in each app? Can I not mount them in some apps?
Network: Does each APP get a network or each container? I'm a bit unclear on the naming and distinction between container and app. Does rkt provide "out of the box" network at all? Docker's got this part pretty well, even if it is terribly slow.
AC_APP_NAME - what does "the entrypoint that this process was defined from" mean?
Isolators: Who do I have to beg to NOT reinvent this, and instead use something derived from LMCTFY? We have captured YEARS of development in LMCTFY's concepts. For example, exposing CPU shares is a mess. If there are things about LMCTFY's structures that don't work, let's iron those out instead..
You say "if the ACE is looking for example.com/reduce-worker-1.0.0 it will request: https://example.com/reduce-worker?ac-discovery=1". What principle lead to some piece of software knowing where to split that string?
You make some remark about /etc/hosts being assumed present and parsed by libc. Does this mean you won't provide /etc/hosts, /etc/resolv.conf, etc? That seems like a bad idea.
meanYou say config-drives "make assumptions about filesystems which are not appropriate for all environments" - can you explain? Why is it not sufficient to say that config can also be found in a volume, if the user so prefers? The host environment should be able to provide that.
"name": "example.com/reduce-worker-1.0.0" - why is version just jammed in there? Or are you trying to say "version is opaque" and if you want it, you have to embed it in the name?
Can we define user and group as name strings, not as numerics (and why are they string numbers?)
Why do you need a private network flag? This hasn't really answered how networking will work. This has been a huge PITA with Docker because EVERYONE has a different idea of what they want in networks. You can NOT support flags for all of them, so I'd argue to support none of them and instead define that as a plugin, and ship some examples of network plugins but leave it open.
Copied from original issue: rkt/rkt#151
The text was updated successfully, but these errors were encountered: