Change:
// Rkt-specific settings. fs.StringVar(&s.RktPath, "rkt-path", s.RktPath, "Path of rkt binary. Leave empty to use the first rkt in $PATH.  Only used if --container-runtime='rkt'.") <ins> fs.MarkDeprecated("rkt-path", "will be removed in a future version. Rktnetes has been deprecated in favor of rktlet (https://github.com/kubernetes-incubator/rktlet).") </ins> fs.StringVar(&s.RktAPIEndpoint, "rkt-api-endpoint", s.RktAPIEndpoint, "The endpoint of the rkt API service to communicate with. Only used if --container-runtime='rkt'.") <ins> fs.MarkDeprecated("rkt-api-endpoint", "will be removed in a future version. Rktnetes has been deprecated in favor of rktlet (https://github.com/kubernetes-incubator/rktlet).") </ins> fs.StringVar(&s.RktStage1Image, "rkt-stage1-image", s.RktStage1Image, "image to use as stage1. Local paths and http/https URLs are supported. If empty, the 'stage1.aci' in the same directory as '--rkt-path' will be used.") <del> fs.MarkDeprecated("rkt-stage1-image", "Will be removed in a future version. The default stage1 image will be specified by the rkt configurations, see https://github.com/coreos/rkt/blob/master/Documentation/configuration.md for more details.") </del> <ins> fs.MarkDeprecated("rkt-stage1-image", "will be removed in a future version. Rktnetes has been deprecated in favor of rktlet (https://github.com/kubernetes-incubator/rktlet).") </ins> }

Discussion:
rktnetes is the old, in-tree rkt integration. is new integration via CRI. We should deprecate and remove the rktnetes integration once rktlet is ready to take over. Based on the , I think we can announce the deprecation of rktnetes once rktlet is ready, and remove the integration after one more release. /cc who have been working on rktlet who are the owners of rktnetes
cc who once asked me about this confusion and I suggested him to do a clean up. _<
Thanks, very glad to do the clean up part. Is there any plan for deprecation part?
It depends on the progress of rktlet. The folks who are currently working on rktlet and are migrating off rktnetes would be a better source.
It was included in sig-node's 1.9 planning draft, and discussed at sig-node meeting. It was removed for 1.9 because 1) the user (for example: blablacar) is currently depending on it 2) rktlet is under development. We can announce the deprecation now to prevent more users from using it. Once rktlet is done, we can remove it completely.
We're currently working towards an initial rktlet release, which will be tested by Blablacar. We'll give an update next week with the progress.
what's the current progress of the rktlet release?
Hi sorry for the late reply. We plan on releasing rktlet 0.1.0 this week. In that release we implement basic support for the CRI including fetching images, running pods, CNI networking, logging and exec. We pass 129/145 e2e conformance tests. Some features (e.g. attach, port forward) are not implemented so we don't yet consider it ready for deprecating rktnetes. Those features were out of scope for the work we were contracted to do so I’m not sure when it will be completed.
thanks for the update! I don't think rktnetes ever supports attach or port forward, so I don't think they should be the blocker for deprecating rktnetes. Adding to confirm.

(rktlet maintainers), I'd like to aim at officially deprecating rktnetes in k8s v1.10 (and encourage users to move to rktlet). Do you think this is reasonable? We can discuss more in the sig node meeting or on slack if you have concerns.
From the today's sig-node meeting, current rktlet maintainers ( etc) mentioned that they may not have spare cycles to work on rktlet this release, but even as of today, rktlet already passes more tests than rktnetes. Given that, I propose we deprecate rktnetes in 1.10, and remove the code in the next release. The deprecation process includes Send out a deprecation announcement to kubernetes-users kubernetes-dev and kubernetes-sig-node@ with links to rktlet. Add deprecation warning to kubelet when --container-runtime is set to rkt. Can someone from the CoreOS (owner of rktnetes and initiator of rktlet) comment on whether the plan is okay?
/cc
LGTM, do you need any help from our side?
I haven't been involved in active rkt development for a while, but this plan sounds fine to me based on everything I know about the latest rktnetes work.
The plan sounds good to me. The only concern I have is whether Blablacar needs rktnetes for a longer time (cc
I'd love to hear Blablacar's feedback on this. At the same time, I think it might be reasonable for Blablacar not to upgrade kubernetes until they are ready. There hasn't been much active development in rktnetes, so staying on a known, good version, is better than upgrading kubernetes anyway IMO.
I think the rktnetes maintainers are the best candidate to send out the deprecation announcement :-) Adding deprecation warning is trivial. If anyone wants to help, that'd be great.
Sorry for the delay, I was off last week. We (BlaBlaCar) are moving away from rktnetes implementation so it's ok for us if it gets deprecated. Thanks for asking :)
has sent out the announcement. Will close this once the PR gets merged.
Seems like is dead and does not support v1.10.