One of the things which was brought up in #606 was the idea to allow for pausing execution after a disposable client is spawned so that a dev can update the disposable client before the actual task execution starts.
Original text from #606:
This will be most probably necessary, because no matter what magical solution we come up with (if we do), we'll not cover all use cases and people will need to manually adjust it from time to time. This can be in a form of pausing before execution, or having something like runtask --create-disposable-client, doing what we need to do, and making use of runtask --ssh ip. This still does not solve the ease of use, it just allows you to do it manually.
Propose runtask cli arguments for this and implement the proposal.
runtask
This ticket had assigned some Differential requests: D960
Maybe we can suggest users build their tailored image using testcloud:they can use testcloud (with base.qcow2) to create a VM(named:testvm),and install packages and do some configure on that machine,and then they can create VMs on top of /var/lib/testcloud/instances/testvm-local.qow2,bingo,their is no need for them to modify the disposable VM anymore for that kinds of test.Yeah,they should keep on mind that they definitely can't remove base.qcow2 ,that's a little annoying,but we can use virsh blockpull to perfectly handle that.Actually,I'm thinking that maybe we can provide users images with dependencies pre-installed using this method.
Though there is less need to add the pause option ,but I have tried to modify the libtaskotron ,below is the ugly method : add a pause-vm option in main.py and modify the minion.py
def _run(self): '''The main method that runs the task''' task =os.path.join(self.taskdir,os.path.basename(self.arg_data['task'])) cmdline = python_utils.reverse_argparse(self.arg_data['_orig_args'], ignore=self.arg_data_exclude) cmdline.append('--local') cmdline.append(task) # be paranoid and escape everything cmdline = [pipes.quote(elem) for elem in cmdline] # check if pause-vm is set if self.arg_data['pause-vm']: user_choice = True instance_name = 'taskotron-{}'.format(self.arg_data['uuid']) tasktron_ip = cli.find_vm_ip(instance_name) log.info("ssh root@ %s in another terminal to customize your VM,and Ctrl+C this when it is done",tasktron_ip) while user_choice: try: # wait for users to customize their VM sleep(1000) # exit this loop by set user_choice to True when '^C' is received except KeyboardInterrupt: user_choice = False log.info("receive Ctrl+C, continue the libtaskotron task") # execute task log.info('Executing the task on the minion...') task_cmd = ['cd', pipes.quote(self.taskdir), '&&', 'runtask'] + cmdline self.exitcode = self.ssh.cmd(' '.join(task_cmd)) log.info('Task execution on the minion is complete.')
Or ,we can add a no-pause-vm argument instead, and don't pause the program when that argument is added.
Actually,I'm thinking that maybe we can provide users images with dependencies pre-installed using this method.
Yes, that is our plan.
add a pause-vm option in main.py and modify the minion.py
Please create a diff and link it here, it's hard to read code in comments (especially when you don't enable syntax highlighting, which you can do, click the help icon) and impossible to comment particular lines.
(Btw, you can edit a comment, you don't need to delete it and create a new one. Just a tip.)
! In #675#11572, @kparal wrote: Actually,I'm thinking that maybe we can provide users images with dependencies pre-installed using this method. Yes, that is our plan.
As I said in T568,I'd like to take the first step if you are busy with making more important contributions:)
Please create a diff and link it here, it's hard to read code in comments (especially when you don't enable syntax highlighting, which you can do, click the help >icon) and impossible to comment particular lines. (Btw, you can edit a comment, you don't need to delete it and create a new one. Just a tip.)
Gonna to do,you are always so helpful^^
I'm sorry I'm telling you too late (when you already have some code), but we were discussing this internally and after looking into this in detail we're not sure we need this new option right now. This ticket has been created a long time ago, and now we already have a way to work around this by using --no-destroy and --ssh. So we're not sure having yet another option just for this is worth it (making code more complex). I think it would be best to freeze this ticket right now, and resume work on it if there are such requests from our users in the future. The patch will stay available in Phabricator and we can apply it later if we need it. Sorry once again.
--no-destroy
--ssh
! In #675#11623, @kparal wrote: I'm sorry I'm telling you too late (when you already have some code), but we were discussing this internally and after looking into this in detail we're not sure >we need this new option right now. This ticket has been created a long time ago, and now we already have a way to work around this by using --no-destroy >and --ssh. So we're not sure having yet another option just for this is worth it (making code more complex). I think it would be best to freeze this ticket right >now, and resume work on it if there are such requests from our users in the future. The patch will stay available in Phabricator and we can apply it later if we >need it. Sorry once again. I should have worked on this ticket first,not others,when you offered it to me three weeks ago:( As for the --no-destroy and --ssh combination,from my green vision,I only see one not so gentle method :first,run task with --no-destroy,wait until the this task finished(at least after start the VM);then,ssh to the disposable VM to do some manual work;Finally,run task with --ssh.So we have to run a task two times.However,I think it's pretty OK for me to freeze this ticket for three reasons:first,my code is not so gentle,it can only save a little time for users compared to --no-destroy and --ssh combination;second,as I said when I submitted the code,there will be less need to add the pause option if we suggest users to use the method I mentioned in the comment;Finally,I agree with you,we'd better not add one option just for this.So,don't feel sorry: )
Setting this ticket as wontfix for this moment. We can come back to it in the future if there's user demand.