
App Container Spec One Week In - jzelinskie
https://coreos.com/blog/appc-one-week-in/
======
tlrobinson
"With discussions starting on implementing the spec in [...] Docker"

I guess that depends on who you ask at Docker...

[https://github.com/docker/docker/issues/9538#issuecomment-65...](https://github.com/docker/docker/issues/9538#issuecomment-65967102)

To be fair, the filing of this "Docker is not compatible with ACL" issue is a
bit premature when the spec barely exists yet.

~~~
ascendantlogic
Sad that the issue was closed with a 3 paragraph long diatribe laced with
venom. For someone that talked a lot about taking the high road from a PR
perspective, Solomon has certainly not missed an opportunity to get really
worked up in various forums over this.

~~~
ubernostrum
The reply seemed strong but on-point and reasonable. Why should Docker break
compatibility and abandon what appears to be a pretty serious amount of
consensus from a large number of pretty serious industry players, in order to
comply with a startup's 3-day-old unfinished "standard" for their "we're
building the next Docker, but incompatible with Docker, give us money now
please" business plan?

Especially when the request was not worded as "we're trying to standardize
this, want to help out", but "we ARE the standard, comply with us".

CoreOS comes off in this exchange looking the very worst sort of VC vaporware
wannabes, and that's what I'm going to remember a year or two down the line
(assuming they even still exist at that point) if faced with an actual choice
involving them.

~~~
efuquen
You realize the issue wasn't opened by someone at CoreOS, or the discussion
before Solomon's diatribe wasn't forceful or in bad faith? @jfrazelle actually
had the diplomatic answer right there, not this "defending my turf attitude".
The attitude seems to be "you must use the Docker container spec or gtfo".
That's not the attitude of a friendly OSS maintainer but more so of a private
interest viciously protecting themselves.

I had no negative opinion about either company but to me it's clear Solomon
has come off very poorly and undiplomatic from this whole exchange. CoreOS has
done nothing wrong, they are not obligated to do whatever Docker Inc. or
Solomon wants them to do. And of course neither does Docker have to do
whatever CoreOS maintainers might want of them, but one side is mudslinging
and bickering while the other isn't, very childish IMHO.

~~~
necrodawg
I'm sorry but this is exactly the kind of leadership Docker needs right now.
He reminds me a bit of Linus Torvalds and Theo de Raadt in his responses.
Doesn't take shit from anyone, doesn't try to please everyone and gets shit
done. Exactly what Docker as a project is doing.

~~~
efuquen
Has Linus ever gotten bent out of shape at somebody for forking Linux
(assuming they've done it while not violating the license)? Let alone someone
who would decide to do their own clean implementation of a Linux like OS? I
don't think that comparison makes much sense.

EDIT: Let the users work this out, if Rocket fulfills a need for some people
better than Docker does for CoreOS then it will become clear overtime. Docker
does need leadership, but not by picking pointless fights.

~~~
necrodawg
I think you're referring to another post now. I doubt they eat the same
breakfast either. I was specifically referring to this github ticket.

I think the users have already decided, pretty much everyone uses docker
already.

------
jaequery
I don't know about rest of you but at our company we went through a lot of
pain dealing with CoreOS. If we had known sooner, I'd gladly have taken a
minimal Ubuntu to run Docker over CoreOS. For one, requiring reboot to update
is astrocious! Because of these experiences, I just don't much faith in CoreOS
guys (at least not yet), and the standard they are creating I think kills the
best aspect of Docker, the freedom!

And regards to @shykes response, he was right on all points. Who in their
right mind would adopt a supposed "Standard" written only 3 days ago? Doesn't
matter who wrote it, it is just very unreasonable to accept a Standard without
putting it through the test of time. This is a Standard, once in place you
can't really change later, so aren't you glad that they didn't just jump on
things?

Also, if you are in Docker's position, why would you want to risk limiting
yourself to a single standard? Things change, fads change, people come up with
better ideas, etc... No one knows. Some may want a much simpler spec (I for
one), others may want something more thorough and detailed, etc. Just let the
people decide the standard and let it run it's course, eventually the best
will come out on top.

~~~
avtar
_at our company we went through a lot of pain dealing with CoreOS. If we had
known sooner, I 'd gladly have taken a minimal Ubuntu to run Docker over
CoreOS. For one, requiring reboot to update is astrocious!_

As someone who hasn't invested a lot of time in evaluating CoreOS yet I would
be interested in hearing about what other pain points you encountered. The
reboot to update requirement seems straightforward given what they state in
their documentation [https://coreos.com/using-
coreos/updates/](https://coreos.com/using-coreos/updates/)

------
kelseyhightower
For those looking for a little more context or who want to see the App
Container Spec in action we recorded videos following the initial announce of
Rocket -- the initial implementation of the spec.

Rocket & App Container Spec Overview by Brandon Philips -
([https://www.youtube.com/watch?v=GYgpaAZMe-E](https://www.youtube.com/watch?v=GYgpaAZMe-E))

Rocket Tutorial and Demo by Kelsey Hightower -
([https://www.youtube.com/watch?v=E9WVjxaRkKU](https://www.youtube.com/watch?v=E9WVjxaRkKU))

Google Hangout with CoreOS: Rocket and the App Container Spec -
([https://www.youtube.com/watch?v=U3UmFQbUsN8](https://www.youtube.com/watch?v=U3UmFQbUsN8))

~~~
darkarmani
Is there any discussion around why you require all container images to be
signed? I understand that you want to provide a means to identifying that user
X signed (well key Y signed it -- hopefully that is user X) the container, but
it's putting the cart before the horse.

Maybe I'm missing something, but this completely ignores that the biggest
security issue is people and process. You can't require people to have good
process. IMHO, requiring gpg signatures _WEAKENS_ security, because the people
that don't care or don't have strong security requirements are going to play
fast and loose with their keys. If you don't require gpg signatures, you can
let those people signal their lack of security by having "naked" images. (ie:
a security audit will catch that really fast and then force a reasoned
discussion about key trust)

Requiring gpg signatures gives the illusion that all of the images are somehow
more secure.

------
kevinburke
I'm wondering whether it's a good idea to pay too much attention to a project
early on in its design; whether it can lead to a worse interface/less
iteration loops vs. a bunch of smart people working and iterating on an idea
in private.

~~~
dubcanada
I tend to believe it's better to keep it private and then introduce it later
on when a beta or alpha is done and get feedback then iterate.

People have too many opinions about stuff.

~~~
Khao
I think the hard part will be to try and stay focused and establish
milestones. If everyone is giving input at the same time, it'll be extremely
spread out and inefficient. Working towards the first few releases (0.1, 0.2,
etc..) you need to be really focused on your priorities and not distracted by
the big picture too much.

