5 ms·

App Container Spec One Week In

103 points by jzelinskie 12y ago

kevinburke 12y ago
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 12y ago
  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 12y ago
    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.
kelseyhightower 12y ago
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 12y ago
  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.
tlrobinson 12y ago
"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-65967102 https://github.com/docker/docker/issues/9538#issuecomment-65... 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 12y ago
  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.
  - the_real_bto 12y ago
    I don't see the venom. I see someone who is taking a lot of flak from internet experts and probably too eager to satisfy them, when such a thing is impossible. What is Solomon supposed to do? He explained very clearly his thoughts about standards. It's actually a very reasonable (if a bit defensive) response.
    - ascendantlogic 12y ago
      I mean, the issue just says "support this standard" and it's an explosion of...I guess what is deemed as non-venom? He could have just closed it and said "Not at this time" or something like that.
      - zaphar 12y ago
        The issue says and I quote: Docker should adhere to the App Container Image (ACI) specification. That's a more forceful wording than "support this standard". I might not have used the same tone as Solomon here but the issue is not exactly worded diplomatically either, particularly given the current tone right now around these two projects.
jaequery 12y ago
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 12y ago
  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/

103 points by jzelinskie 12y ago

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 12y ago
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 12y ago
  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.

kelseyhightower 12y ago

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 12y ago
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.

tlrobinson 12y ago

"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-65967102 https://github.com/docker/docker/issues/9538#issuecomment-65... 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 12y ago
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.
- the_real_bto 12y ago
  I don't see the venom. I see someone who is taking a lot of flak from internet experts and probably too eager to satisfy them, when such a thing is impossible. What is Solomon supposed to do? He explained very clearly his thoughts about standards. It's actually a very reasonable (if a bit defensive) response.
  - ascendantlogic 12y ago
    I mean, the issue just says "support this standard" and it's an explosion of...I guess what is deemed as non-venom? He could have just closed it and said "Not at this time" or something like that.
    - zaphar 12y ago
      The issue says and I quote: Docker should adhere to the App Container Image (ACI) specification. That's a more forceful wording than "support this standard". I might not have used the same tone as Solomon here but the issue is not exactly worded diplomatically either, particularly given the current tone right now around these two projects.

jaequery 12y ago

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 12y ago
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/