--
You received this message because you are subscribed to the Google Groups "dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.
So, is there will be "action" to get state? Because I'm not sure that
removing state from spec totally is possible. However I agree that
probably hardcoded fs schema brings more harm, than good.
So, is there will be "action" to get state? Because I'm not sure that
removing state from spec totally is possible. However I agree that
probably hardcoded fs schema brings more harm, than good.What is an "action"?
I've been thinking of this slightly differently. I've been considering this more from the data perspective. Meaning, who should have access to the state file?
1 - the state file is an internal processing thing and therefore where it is stored is up to the impl to decide. If an unprivileged use of runc happens then runc needs to make sure the state is stored in a place it has write access to. Not our problem from a spec perspective. However, I then view this as implying we must standardize on a cmd line so that we can interoperably ask something like "runc --id myapp state" and expect back the json file.
2 - the state file is shared. This is what we have/do to day and to ensure interop we need to specify where it goes. While the spec say it MUST be in a certain dir, I guess we could change that to we "STRONGLY RECOMMEND" that dir, and give fair warning that not doing so hurt interop.
I don't have a good sense for how 3rd party tooling would prefer to access this information but I have to admit that I like option 1 because it allows for impls to store their state in a DB, and keeps that decision hidden from the user/tooling. It also avoids some of the sync/deadlock/mux issues people have mentioned concerning file access. Of course, it also forces a different model on us. Today each instance of runc is (for the most part) independent of each other - with #1 this isn't true because the 2nd instance of runc (e.g. runc state) needs to be able share info with other instances and I wonder if there are any pitfalls we'll run into w.r.t. defining the scope of this data sharing?
thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | d...@us.ibm.com
The more I'm around some people, the more I like my dog
"W. Trevor King" ---01/06/2016 04:05:10 PM---On Tue, Dec 08, 2015 at 03:49:57PM -0800, W. Trevor King wrote: > As Brandon pointed out, maintainin
[attachment "signature.asc" deleted by Doug Davis/Raleigh/IBM]