appearntly it is complicated to set this during pool creation. we can live with that for now, but the field should still appear on the 'new pool dialog' in grayed out with a tooltip explaining it can be set when the pool is created.
note i'm not sure how the race between pre-strted vms for pool creation is different from when extending the pool, so maybe we do just need to fix it.
muli - can you please elaborate on the reasoning for this limitation per my comment 1?
related to bug 835000 as well (which just tracks the UI layout)
(In reply to comment #1) > note i'm not sure how the race between pre-strted vms for pool creation is > different from when extending the pool, so maybe we do just need to fix it. True. The same problem arises when we extend a pool, since we don't want the new vms to be part of the prestarted batch, until the administrator says so. This is due to cases such as the need to sysprep the vm by the admin, before prestarting. Possible solutions include adding a new parameter per pool, that indicates whether prestarting is currently enabled.
*** Bug 844913 has been marked as a duplicate of this bug. ***
> but the field should still appear on the 'new pool dialog' in grayed out with a > tooltip explaining it can be set when the pool is created. Could someone please provide the exact phrasing of this tooltip message?
(In reply to comment #6) > > but the field should still appear on the 'new pool dialog' in grayed out with a > tooltip explaining it can be set when the pool is created. > Could someone please provide the exact phrasing of this tooltip message? I would go with: Prestarted VMs can only be edited once the pool is created
in gerrit: http://gerrit.ovirt.org/#/c/7173/
(In reply to comment #4) > (In reply to comment #1) > > note i'm not sure how the race between pre-strted vms for pool creation is > > different from when extending the pool, so maybe we do just need to fix it. > > True. The same problem arises when we extend a pool, since we don't want the > new vms to be part of the prestarted batch, until the administrator says so. > This is due to cases such as the need to sysprep the vm by the admin, before > prestarting. Possible solutions include adding a new parameter per pool, > that indicates whether prestarting is currently enabled. I created a pool and then immediately edited it and changed pre-started without syspreping, so the above exists regardless and hence not a good reason to block user from setting it in create flow. If user wants to first sysprep then when creating the pool he won't set anything to prestarted. I also don't see the big deal in the VM being started and then admin restarting it with the sysprep disk attached.
isn't the patch for this and bug 835000 solving it the same way (gui only change for now. release note on behavior implications i guess?) close on as duplicate or move this one to future to allow this setting?
well, Ayal disagreed with my rhevm_future in 835000. Otherwise it is indeed about the same thing. The GUI change is not that radical as the vcpu editing so maybe its not too late to change it. Ill discuss with Tomas and if were going to proceed with 835000 now we can abandon this one
dupe to 835000 as it solves this issue *** This bug has been marked as a duplicate of bug 835000 ***