Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing rkt v0.5, featuring pods, overlayfs, and more

coreos.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#21

Post by jacques_chester »

vacri wrote: post #20
jacques_chester wrote: post #18

Earlier quoted context omitted.

Showing 404 to hide the existence of a resource is specifically called out as a suitable use in the RFCs: The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. http://tools.ietf.org/html/rfc7231#section-6.5.4

This being said, 403 is also valid in that same RFC, and makes more sense. "You are not authorised to know the status of this item" is more informative and less misleading than "This item doesn't exist". Everything should be auth-restricted by default (deny-by-default), except for items intentionally made public. In my example above, a 403 gives the correct nature of the fault without revealing any hidden information…

A 403 only works in the case that you have an all-or-nothing authentication scheme.

A 403 for a resource that exists but is unauthorised leaks the information that the resource exists.

Many Github customers don't want people to be able to guess at their private repos, and the 404 is the only code that is legitimately able to express the union of "not here" and "not here because you're not allowed to know it's here".

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#22

Post by vacri »

jacques_chester wrote: post #21
vacri wrote: post #20

Earlier quoted context omitted.

This being said, 403 is also valid in that same RFC, and makes more sense. "You are not authorised to know the status of this item" is more informative and less misleading than "This item doesn't exist". Everything should be auth-restricted by default (deny-by-default), except for items intentionally made public. In my example above, a 403 gives the correct nature of the fault without revealing any hidden information…

A 403 only works in the case that you have an all-or-nothing authentication scheme. A 403 for a resource that exists but is unauthorised leaks the information that the resource exists. Many Github customers don't want people to be able to guess at their private repos, and the 404 is the only code that is legitimately able to express the union of "not here" and "not here because you're not allowed to know it's here".

Not at all. If I have a private repo "foo" and a public repo "bar" and no others, given an unauth'd request:

    > request "foo" => 403
    > request "bar" => 200
    > request "baz" => 403
    > request "qux" => 403
The unauth'd requester can't tell that foo exists and baz and qux do not.

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#23

Post by wmf »

krakensden wrote: post #10

It's weird seeing all the careful description of a Pod, which is just an explicit rollback of Docker's wishful thinking about single-process containers to something identical to what you'd get with LXC. Which just runs /sbin/init. The amount of wasted development effort caused by Docker's willful intransigence on this is sort of staggering. The teams I work with using docker are still tripping over new nonsense that…

I can imagine that composing a pod out of container images could have advantages over composing a system out of packages because communication between the containers would be more explicit.

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#24

Post by jsprogrammer »

vacri wrote: post #22
jacques_chester wrote: post #21

Earlier quoted context omitted.

A 403 only works in the case that you have an all-or-nothing authentication scheme. A 403 for a resource that exists but is unauthorised leaks the information that the resource exists. Many Github customers don't want people to be able to guess at their private repos, and the 404 is the only code that is legitimately able to express the union of "not here" and "not here because you're not allowed to know it's here".

Not at all. If I have a private repo "foo" and a public repo "bar" and no others, given an unauth'd request: > request "foo" => 403 > request "bar" => 200 > request "baz" => 403 > request "qux" => 403 The unauth'd requester can't tell that foo exists and baz and qux do not.

Right, but if someone requests:

    > request "lkj3fla3kjf1ljf3jf"
Which doesn't exist anywhere, it makes no sense to return 403.

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#25

Post by jsprogrammer »

jzxcv wrote: post #19
zobzu wrote: post #13

This is cool. Overlayfs IS a huge difference in performance due to fs level caching amount namespaces. Hopefully btrfs will get that too, some day. I must say however, I dont like the pod concept too much. That locks you in a bit. Additionally and in a different register, the deployment systems, while these work fine when you have to the time to do things right, dont work so well in practice. All companies that I kno…

Could you explain what you mean by "locks you in"?

You now have to run all those programs in the same namespace, on the same machine. There is no possibility to run some of the programs somewhere else (without building a new image).

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#26

Post by tb93 »

jsprogrammer wrote: post #25
jzxcv wrote: post #19

Earlier quoted context omitted.

Could you explain what you mean by "locks you in"?

You now have to run all those programs in the same namespace, on the same machine. There is no possibility to run some of the programs somewhere else (without building a new image).

No, pod is a collection of multiple images, not a single fat one.

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#27

Post by jsprogrammer »

tb93 wrote: post #26
jsprogrammer wrote: post #25

Earlier quoted context omitted.

You now have to run all those programs in the same namespace, on the same machine. There is no possibility to run some of the programs somewhere else (without building a new image).

No, pod is a collection of multiple images, not a single fat one.

Sorry, you have to rebuild the top level representation, which I guess is now called a Pod.

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#28

Post by tb93 »

jsprogrammer wrote: post #27
tb93 wrote: post #26

Earlier quoted context omitted.

No, pod is a collection of multiple images, not a single fat one.

Sorry, you have to rebuild the top level representation, which I guess is now called a Pod.

No, Pod is designed for multi-containers grouped to run on the same host, primarily for sidekick process, like syslog.

If you want to multi-host deployment, it is similar to CloudFormation. You can still use multiple pods to compose a distributed app.

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#29

Post by IanCal »

vacri wrote: post #20
jacques_chester wrote: post #18

Earlier quoted context omitted.

Showing 404 to hide the existence of a resource is specifically called out as a suitable use in the RFCs: The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. http://tools.ietf.org/html/rfc7231#section-6.5.4

This being said, 403 is also valid in that same RFC, and makes more sense. "You are not authorised to know the status of this item" is more informative and less misleading than "This item doesn't exist". Everything should be auth-restricted by default (deny-by-default), except for items intentionally made public. In my example above, a 403 gives the correct nature of the fault without revealing any hidden information…

> "You are not authorised to know the status of this item" is more informative and less misleading than "This item doesn't exist"

Well the RFC says a 404 basically means "this item doesn't exist, or I can't tell you if it does". If you ignore part of the definition, then sure, it doesn't make sense. Including that last part, then of course it makes sense for this case!

If you returned 403's, I can see people complaining that they should have access to their own images and they've logged in and checked their password/etc only to find out they've spelled the name wrong. A 403 also does not seem, to me, to cover the case where an item does not exist but a 404 definitely covers the case where it exists but can't disclose that fact.

Really the solution here would have been to, when seeing a 404, say to the user:

"The image iancal/thing either does not exist or you do not have access to see it. If you believe the image exists, please ensure you are logged in and have appropriate access rights"

Re: Announcing rkt v0.5, featuring pods, overlayfs, and more

#30

Post by krakensden »

wmf wrote: post #23
krakensden wrote: post #10

It's weird seeing all the careful description of a Pod, which is just an explicit rollback of Docker's wishful thinking about single-process containers to something identical to what you'd get with LXC. Which just runs /sbin/init. The amount of wasted development effort caused by Docker's willful intransigence on this is sort of staggering. The teams I work with using docker are still tripping over new nonsense that…

I can imagine that composing a pod out of container images could have advantages over composing a system out of packages because communication between the containers would be more explicit.

I see it as a hassle- I dont want to be doing a bunch or redundant whitelisting to make the percona tools work. Worse, I don't want to ship them separately, xtrabackup uses mysql as a library, which means separate containers only buys you bugs.

Docker's design decisions make sense if you're shipping statically linked, standalone binaries everywhere. Which I suspect docker.io and many other people are doing. But that's also sort of a boring edge case where you don't even need filesystem namespaces except for cleanliness.

Post reply on HN