3 ms·

> You seem to not understand what ACI is I know exactly what the app container spec is...stop being patronizing. My point was that I have to use CoreOS FOR ORC

by curun1r 12y ago

> You seem to not understand what ACI is I know exactly what the app container spec is...stop being patronizing. My point was that I have to use CoreOS FOR ORCHESTRATION because my normal options for orchestration don't (yet) work with Rocket or any of its implementations. I know CoreOS has publicly announced that they'll make Kubernetes work with Rocket, but that's not yet reality. And the orchestration option that we're currently pursuing, ECS, isn't likely to support Rocket any time soon. And CoreOS doesn't exactly have a great history of being interoperable...the tools that make up CoreOS have hard dependencies on each other. For example, I find Consul to be better than etcd in almost every conceivable way and yet CoreOS forces me to run etcd. I'm not going to believe that CoreOS cares about interoperability until they're willing to take the same "batteries included but removable" stance that Docker has professed. You seem to have a very pro-CoreOS bias. I'm not going to try to change that. Let me be clear on my biases. I like the design of Rocket far more than Docker. I don't want a single executable to build, run, monitor processes and be a REST API. But I also disagree with almost every decision that's gone into CoreOS. Fleet is cumbersome, systemd is a train wreck (the one thing an init system cannot be is non-deterministic and I've seen too many systemd boot sequences be that) and etcd is inferior to other options. So while I respect that Rocket can be used elsewhere, there's still little-to-no support outside of CoreOS when it comes to everything that goes into running containerization in a production environment. My company has serious dev-test-prod workflow issues that can be solved by containerization. We're publicly tied to running in AWS. CoreOS is simply a non-starter. While I completely agree with all the negative things that have been said about Docker, I can still advocate Docker-based solutions in the meetings I attend on this subject because everything I need from the ecosystem is there, today, ready to use. Rocket simply isn't there yet and it could have been if they'd started with the existing Docker implementation as the basis for their specification. And you're not going to convince me that that NIH decision is in the best interests of the community.

Alupis 12y ago
> Rocket simply isn't there yet and it could have been if they'd started with the existing Docker implementation as the basis for their specification It's not "their" specification. You really don't get what the ACI is. Nobody owns or controls the ACI -- it's a community specification being worked on and developed by a community, ie. no one entity dictates what it looks like. > I find Consul to be better than etcd in almost every conceivable way and yet CoreOS forces me to run etcd This is out of the scope of this discussion. Rocket runs on any Linux. ACI implementation run on any 'nix currently. There is not interoperability issues here. etcd is part of CoreOS the Operating System. However, you can use etcd outside of CoreOS the Operating System. This complaint is like saying your don't like iptables in RHEL 6.x and since it's not easy to change out, you refuse to use Wayland. It makes no sense. > I can still advocate Docker-based solutions in the meetings I attend on this subject because everything I need from the ecosystem is there, today, ready to use. Perhaps this is a sign that contanerization is simply not ready for mainstream enterprise use yet. Sure, Docker stamped the big "1.0" to impress investors and Red Hat, but that doesn't mean it's actually really ready for the big time. Especially since other offerings are rapidly brewing. You've gone this long without containers, you can definitely wait another 6 months (or switch to BSD and use jail containers which have been mature for 15+ years). > I'm not going to believe that CoreOS cares about interoperability until they're willing to take the same "batteries included but removable" stance that Docker has professed Again -- you don't seem to understand what the ACI is. It's a community thing -- CoreOS doesn't own it. That guarantees interoperability. The ACI specifies what a container should look like to be "standards compliant". It's up to the specific implementation to make a system that works with that standard container format. The system can be implemented in any language, work any way they want, do anything they want, etc... so long as it can read and understand the standard container format. If that is not "interoperability", I don't know what is. > You seem to have a very pro-CoreOS bias No, I don't. I have a very pro-Open Standard bias. The world does not need another vmdk.

by curun1r 12y ago

Alupis 12y ago

> Rocket simply isn't there yet and it could have been if they'd started with the existing Docker implementation as the basis for their specification It's not "their" specification. You really don't get what the ACI is. Nobody owns or controls the ACI -- it's a community specification being worked on and developed by a community, ie. no one entity dictates what it looks like. > I find Consul to be better than etcd in almost every conceivable way and yet CoreOS forces me to run etcd This is out of the scope of this discussion. Rocket runs on any Linux. ACI implementation run on any 'nix currently. There is not interoperability issues here. etcd is part of CoreOS the Operating System. However, you can use etcd outside of CoreOS the Operating System. This complaint is like saying your don't like iptables in RHEL 6.x and since it's not easy to change out, you refuse to use Wayland. It makes no sense. > I can still advocate Docker-based solutions in the meetings I attend on this subject because everything I need from the ecosystem is there, today, ready to use. Perhaps this is a sign that contanerization is simply not ready for mainstream enterprise use yet. Sure, Docker stamped the big "1.0" to impress investors and Red Hat, but that doesn't mean it's actually really ready for the big time. Especially since other offerings are rapidly brewing. You've gone this long without containers, you can definitely wait another 6 months (or switch to BSD and use jail containers which have been mature for 15+ years). > I'm not going to believe that CoreOS cares about interoperability until they're willing to take the same "batteries included but removable" stance that Docker has professed Again -- you don't seem to understand what the ACI is. It's a community thing -- CoreOS doesn't own it. That guarantees interoperability. The ACI specifies what a container should look like to be "standards compliant". It's up to the specific implementation to make a system that works with that standard container format. The system can be implemented in any language, work any way they want, do anything they want, etc... so long as it can read and understand the standard container format. If that is not "interoperability", I don't know what is. > You seem to have a very pro-CoreOS bias No, I don't. I have a very pro-Open Standard bias. The world does not need another vmdk.