Re: Proposed F19 Feature: Checkpoint/Restore
On Thu, Jan 24, 2013 at 11:11 AM, Adrian Reber adr...@lisas.de wrote: On Thu, Jan 24, 2013 at 11:02:57AM -0500, Josh Boyer wrote: CONFIG_NAMESPACES seems to be required to make all those activated _NS options actually enabled: config-generic:CONFIG_PID_NS=y config-generic:CONFIG_UTS_NS=y config-generic:CONFIG_IPC_NS=y config-generic:CONFIG_NET_NS=y Those might be doable. To make it clear. This already what is in the kernel package and not a change I made. It just needs CONFIG_NAMESPACES to actually be enabled. The kernel team discussed this at last week's public kernel meeting. I think we're comfortable enabling these options. We're going to patch the Kconfig so that it doesn't depend on CONFIG_EXPERT, but aside from that things should be as you suggest. We'd really like to see some kind of testing framework for this though. Do you know of any testcases that could be added to the Fedora kernel testing git tree to cover CRIU? If not, do you think you could create some minimal ones? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Wed, Jan 30, 2013 at 10:13:44AM -0500, Josh Boyer wrote: On Thu, Jan 24, 2013 at 11:11 AM, Adrian Reber adr...@lisas.de wrote: On Thu, Jan 24, 2013 at 11:02:57AM -0500, Josh Boyer wrote: CONFIG_NAMESPACES seems to be required to make all those activated _NS options actually enabled: config-generic:CONFIG_PID_NS=y config-generic:CONFIG_UTS_NS=y config-generic:CONFIG_IPC_NS=y config-generic:CONFIG_NET_NS=y Those might be doable. To make it clear. This already what is in the kernel package and not a change I made. It just needs CONFIG_NAMESPACES to actually be enabled. The kernel team discussed this at last week's public kernel meeting. I think we're comfortable enabling these options. We're going to patch the Kconfig so that it doesn't depend on CONFIG_EXPERT, but aside from that things should be as you suggest. We'd really like to see some kind of testing framework for this though. Do you know of any testcases that could be added to the Fedora kernel testing git tree to cover CRIU? If not, do you think you could create some minimal ones? The userspace part of CRIU (crtools) contains about 100 testcases. Some of them probably require some kernel patches which are not yet upstreamed, but I think that most of them would work. I would be happy to include them in the Fedora kernel testing git tree. No problem. Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Wed, Jan 23, 2013 at 03:37:46PM -0500, Josh Boyer wrote: On Wed, Jan 23, 2013 at 2:35 PM, Jaroslav Reznik jrez...@redhat.com wrote: To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM. The CRIU page doesn't say you need CONFIG_NAMESPACES enabled to use CRIU. Also, there is nothing in the kernel Kconfig dependencies that would select or require that set to turn on CONFIG_CHECKPOINT_RESTORE. Could you be more explicit as to why you need namespaces turned on? CONFIG_NAMESPACES took me some time to find out. I actually need CONFIG_CHECKPOINT_RESTORE which requires CONFIG_EXPERT. I also need (for restore) CONFIG_PID_NS which is enabled in config-generic config-generic:CONFIG_PID_NS=y Looking at the config of a built kernel I see that it is not enabled. Looking at init/Kconfig I see that CONFIG_PID_NS is only enabled if CONFIG_NAMESPACES is enabled. CONFIG_NAMESPACES seems to be required to make all those activated _NS options actually enabled: config-generic:CONFIG_PID_NS=y config-generic:CONFIG_UTS_NS=y config-generic:CONFIG_IPC_NS=y config-generic:CONFIG_NET_NS=y Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Thu, Jan 24, 2013 at 10:58 AM, Adrian Reber adr...@lisas.de wrote: On Wed, Jan 23, 2013 at 03:37:46PM -0500, Josh Boyer wrote: On Wed, Jan 23, 2013 at 2:35 PM, Jaroslav Reznik jrez...@redhat.com wrote: To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM. The CRIU page doesn't say you need CONFIG_NAMESPACES enabled to use CRIU. Also, there is nothing in the kernel Kconfig dependencies that would select or require that set to turn on CONFIG_CHECKPOINT_RESTORE. Could you be more explicit as to why you need namespaces turned on? CONFIG_NAMESPACES took me some time to find out. I actually need CONFIG_CHECKPOINT_RESTORE which requires CONFIG_EXPERT. I also need (for restore) CONFIG_PID_NS which is enabled in config-generic Why does restore need PID_NS? The kernel doesn't think it does, so is this a requirement based on the userspace tooling? config-generic:CONFIG_PID_NS=y Looking at the config of a built kernel I see that it is not enabled. Looking at init/Kconfig I see that CONFIG_PID_NS is only enabled if CONFIG_NAMESPACES is enabled. Right. CONFIG_NAMESPACES seems to be required to make all those activated _NS options actually enabled: config-generic:CONFIG_PID_NS=y config-generic:CONFIG_UTS_NS=y config-generic:CONFIG_IPC_NS=y config-generic:CONFIG_NET_NS=y Those might be doable. I take it you very clearly don't need USER_NS, right? Because that option is not going to be enabled at the expense of the things I listed. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Wed, Jan 23, 2013 at 02:55:53PM -0500, Matthew Miller wrote: On Wed, Jan 23, 2013 at 07:35:50PM +, Jaroslav Reznik wrote: To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM. Is this feature suggesting implementing everything up until that point and waiting for the rest of the changes to trickle down from upstream, or is it suggesting carrying the patches *now* in anticipation? Most of the required changes are already included upstream and need three kernel config options to be enabled. The decision about this whole feature depends mainly on the kernel maintainers if they think these options are ready to be enabled or not. I imported the user-space tools (crtools) which need those three kernel config options. If it is decided this is too experimental then the package can easily be retired again. Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Thu, Jan 24, 2013 at 11:02:57AM -0500, Josh Boyer wrote: On Thu, Jan 24, 2013 at 10:58 AM, Adrian Reber adr...@lisas.de wrote: On Wed, Jan 23, 2013 at 03:37:46PM -0500, Josh Boyer wrote: On Wed, Jan 23, 2013 at 2:35 PM, Jaroslav Reznik jrez...@redhat.com wrote: To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM. The CRIU page doesn't say you need CONFIG_NAMESPACES enabled to use CRIU. Also, there is nothing in the kernel Kconfig dependencies that would select or require that set to turn on CONFIG_CHECKPOINT_RESTORE. Could you be more explicit as to why you need namespaces turned on? CONFIG_NAMESPACES took me some time to find out. I actually need CONFIG_CHECKPOINT_RESTORE which requires CONFIG_EXPERT. I also need (for restore) CONFIG_PID_NS which is enabled in config-generic Why does restore need PID_NS? The kernel doesn't think it does, so is this a requirement based on the userspace tooling? This is a userpace requirement. I can checkpoint without PID_NS, but only restore with PID_NS. config-generic:CONFIG_PID_NS=y Looking at the config of a built kernel I see that it is not enabled. Looking at init/Kconfig I see that CONFIG_PID_NS is only enabled if CONFIG_NAMESPACES is enabled. Right. CONFIG_NAMESPACES seems to be required to make all those activated _NS options actually enabled: config-generic:CONFIG_PID_NS=y config-generic:CONFIG_UTS_NS=y config-generic:CONFIG_IPC_NS=y config-generic:CONFIG_NET_NS=y Those might be doable. I take it you very clearly don't need USER_NS, right? Because that option is not going to be enabled at the expense of the things I listed. I only need PID_NS (and therefore NAMESPACES). All the other options and USER_NS are not required. Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Thu, Jan 24, 2013 at 11:02:57AM -0500, Josh Boyer wrote: CONFIG_NAMESPACES seems to be required to make all those activated _NS options actually enabled: config-generic:CONFIG_PID_NS=y config-generic:CONFIG_UTS_NS=y config-generic:CONFIG_IPC_NS=y config-generic:CONFIG_NET_NS=y Those might be doable. To make it clear. This already what is in the kernel package and not a change I made. It just needs CONFIG_NAMESPACES to actually be enabled. Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: Checkpoint/Restore
= Features/Checkpoint Restore = https://fedoraproject.org/wiki/Features/Checkpoint_Restore Feature owner(s): Adrian Reber adr...@lisas.de Add support to checkpoint and restore processes. Checkpointing processes can be used for fault tolerance and/or load balancing. Checkpointing a process in regular intervals can help to restart a process if it might crash to resume/restart/restore the calculation without too much data lost. Providing this ability transparent at the OS level removes the need to implement this functionality for all processes manually. Checkpointing and restoring a process to another system can be used to migrate a process, process tree or container to another system to distribute the load during the runtime and also for maintenance without service interruption like it is possible with virtual machines. == Detailed description == Checkpointing/restore, as mentioned above, can be used for fault tolerance and load distribution. Fedora can offer checkpoint/restore by using CRIU (Checkpoint/Restore In Userspace). CRIU has been developed with the goal to be accepted by upstream and most patches necessary have already been accepted (as of 2012-10-24) in the kernel. The current release (0.3) of the userspace tools (crtools) offers the ability to checkpoint/restore containers and thus offering the ability to migrate containers. To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Wed, Jan 23, 2013 at 07:35:50PM +, Jaroslav Reznik wrote: To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM. Is this feature suggesting implementing everything up until that point and waiting for the rest of the changes to trickle down from upstream, or is it suggesting carrying the patches *now* in anticipation? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Checkpoint/Restore
On Wed, Jan 23, 2013 at 2:35 PM, Jaroslav Reznik jrez...@redhat.com wrote: To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM. The CRIU page doesn't say you need CONFIG_NAMESPACES enabled to use CRIU. Also, there is nothing in the kernel Kconfig dependencies that would select or require that set to turn on CONFIG_CHECKPOINT_RESTORE. Could you be more explicit as to why you need namespaces turned on? As it stands today, the 3.8 kernel will support UTS, IPC, PID, and NET namespaces seemingly without too much issue. However, USER_NS is still experimental and requires that the kernel doesn't support XFS, NFS, CIFS, NFSD, and GFS2 among others. We can't enable USER_NS because of that, and it's also why we didn't turn it on during the 3.8 merge window. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
