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

11–20 of 33 posts

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

#11

Post by shazow »

bryanlarsen wrote: post #5
conradk wrote: post #2

I'm still wondering what the appc spec has more than Docker (and vice-versa). At the moment, I know Docker and find it easy to use. Why would I use Rocket instead ? Could anyone explain or link to non biased comparisons of the two, please ?

The enhancement I'm most looking forward to is the use of systemd for process management. Docker handles that itself, and can lose track if the process forks strangely and/or badly.

Like postfix. :/

People tend to wrap it with supervisord which does a better job at tracking child processes.

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

#13

Post by zobzu »

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 know of which have 1k employes or less (ie most) basically dont update anything automatically because the redeployment might still fail. And of course, manual labor costs a lot of human resources.

We still need a better way to separate the system update process from the deployment, settings, and app.

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

#15

Post by krakensden »

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…

> I must say however, I dont like the pod concept too much. That locks you in a bit.

They didn't make it up, it's straight from Kubernetes. Presumably the Docker team will wind up incorporating something similar soonish, as well.

That said, it's basically a fancy pants way of saying "we are going to run multiple processes in the same namespace", and if you're using runit like so many people are, you're already doing it.

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

#16

Post by [deleted] »

bryanlarsen wrote: post #5
conradk wrote: post #2

I'm still wondering what the appc spec has more than Docker (and vice-versa). At the moment, I know Docker and find it easy to use. Why would I use Rocket instead ? Could anyone explain or link to non biased comparisons of the two, please ?

The enhancement I'm most looking forward to is the use of systemd for process management. Docker handles that itself, and can lose track if the process forks strangely and/or badly.

[deleted]

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

#17

Post by derefr »

yrro wrote: post #9
NeutronBoy wrote: post #6

Earlier quoted context omitted.

If only there were a separate error code to specifically indicate an authentication problem that could be returned...

Github don't use the error code because to do so would leak information about the names of private repositories.

It would be more correct, then, to signal an authentication error for all nonexistent-and-or-private repos. After all, you aren't authorized to know whether a repo exists by that name or not... whether or not one actually does. (This would also imply that organization owners (and Github CSRs and ops staff) would simply bypass that check, falling through to a check only for existence, where it would be appropriate to return 404.

A similar reasoning is behind why you get a 403, not a 404, when you try to get the index of an empty S3 bucket. Sure, it doesn't exist—but you're also not allowed to know that.

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

#18

Post by jacques_chester »

derefr wrote: post #17
yrro wrote: post #9

Earlier quoted context omitted.

Github don't use the error code because to do so would leak information about the names of private repositories.

It would be more correct, then, to signal an authentication error for all nonexistent-and-or-private repos. After all, you aren't authorized to know whether a repo exists by that name or not... whether or not one actually does. (This would also imply that organization owners (and Github CSRs and ops staff) would simply bypass that check, falling through to a check only for existence, where it would be appropriate to…

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

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

#19

Post by jzxcv »

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"?

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

#20

Post by vacri »

jacques_chester wrote: post #18
derefr wrote: post #17

Earlier quoted context omitted.

It would be more correct, then, to signal an authentication error for all nonexistent-and-or-private repos. After all, you aren't authorized to know whether a repo exists by that name or not... whether or not one actually does. (This would also imply that organization owners (and Github CSRs and ops staff) would simply bypass that check, falling through to a check only for existence, where it would be appropriate to…

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, whereas a 404 is demonstrably misleading.

Post reply on HN