Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-09
20:06:20 mriedem but want it working first
20:06:35 mriedem i want the *mocks* working first
20:08:47 mriedem gee thanks everyone
20:09:09 mriedem what i really need is coffee
20:09:09 dansmith mriedem: basically, we all acknowledge your mundane plight, now get back to work
20:09:11 mriedem and metal
20:09:15 mriedem ha
20:09:18 dansmith :)
20:10:41 mriedem i need comstud here to kick me in my ass
20:11:54 efried I could put you in an armbar, but that would be counterproductive to your typing abilities.
20:12:09 melwitt what's special about comstud kicking you? what about us??
20:12:34 dansmith er, "scaredy"
20:22:13 mriedem melwitt: because you'd probably apologize afterward
20:22:21 mriedem comstud on the other hand...
20:22:44 melwitt heh
20:26:47 openstackgerrit Sujitha proposed openstack/nova master: Add description to policies in admin_password.py https://review.openstack.org/443957
20:28:08 mriedem f yes
20:36:36 openstackgerrit Sujitha proposed openstack/nova master: Add description to policies in admin_password.py https://review.openstack.org/443957
20:37:05 tasker is there a way to "build" a new instance in an un-powered state?
20:42:10 tasker b'ah. probably the wrong channel, but I'm trying to do the above programatticaly.
20:42:10 dansmith you're revising that quota set and un-WIPing them all I assume right?
20:44:50 mriedem dansmith: yeah
20:44:56 mriedem plumber called, more distractoins
20:46:25 efried tasker That doesn't sound... easy. I can think of some ways to hack it. But I don't think the APIs provide anything.
20:46:38 tasker efried: i was afraid of that.
20:47:48 efried tasker Example: create it with no boot disk, and it (maybe) boots into grub/OF. The nova side will see this as "active", so the spawn will succeed, but the VM didn't _really_ boot.
20:48:51 tasker i have an instance with two volumes, one boot, one mounted at /usr. not ideal, but not my instance. i need to be able to, at will, make a backup of the volumes, restore them, and spin up a new copy of the instance. but if the instance boots from 'vda' alone, it'll have problems with no 'vdb' and I can't attach a volume until it's active.
20:49:09 tasker efried: that's not too bad.
20:49:29 mriedem dansmith: like the water in my basement, here comes the flood
20:49:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Decrement quota when deleting an instance in cell0 https://review.openstack.org/443395
20:49:34 openstackgerrit Matt Riedemann proposed openstack/nova master: Temporarily untarget context when deleting from cell0 https://review.openstack.org/443403
20:49:34 efried ...can't attach volume until active, why?
20:49:54 tasker Conflict: Cannot 'attach_volume' while it is in vm_state building
20:50:13 mriedem tasker: i think cburgess is trying to solve a similar issue
20:50:16 mriedem at least with that conflict
20:50:26 mriedem you should join forces
20:50:28 tasker oh? do you have a commit review i can check out?
20:52:11 tasker I'll checkout gerrit and get send a message their way.
20:52:53 mriedem sec
20:54:26 mriedem i thought this https://review.openstack.org/#/c/417541
20:54:49 mriedem tasker: see L33 here for PTG discoussion https://etherpad.openstack.org/p/nova-ptg-pike-cinder
20:54:51 mriedem *discussion
20:55:14 tasker thanks! I'll check it out.
20:55:44 mriedem dansmith: are you checking those changes out? if they look ok at first glance, i'll start working on rebasing on top of gibi's changes
20:55:59 dansmith I will yeah
20:57:50 openstackgerrit melanie witt proposed openstack/nova master: Count resources to check quota for cells https://review.openstack.org/416521
20:58:22 dansmith gross
20:58:35 dansmith well, I don't like the context mocking
20:58:55 dansmith but I shan't hold up on that
21:00:37 cburgess mriedem tasker What did I do?
21:00:59 cburgess mriedem Oh that thing yeah... so thats now part of johnthetubaguy spec on moving to the new cinder attach api
21:03:12 mriedem dansmith: for the assertions?
21:03:19 dansmith mriedem: yeah
21:03:19 mriedem or just the 20 context calls?
21:03:23 dansmith the context calls
21:03:23 mriedem oh
21:03:25 mriedem yeah, well,
21:03:32 mriedem see ^ for the last 3 hours :)
21:03:37 dansmith heh yeah I know
21:05:41 mriedem dansmith: comments in https://review.openstack.org/#/c/437222/
21:05:45 mriedem the notification one
21:06:50 cburgess mriedem So https://review.openstack.org/#/c/417541 should be abandoned. I'll have yuming do that shortly. Our work is now covered by johnthetubaguy work in https://review.openstack.org/#/c/373203/
21:07:12 mriedem cburgess: i can abandon it if you want
21:07:17 cburgess Go ahead
21:07:35 cburgess mriedem Abandon with great abandon.
21:07:49 dansmith mriedem: so in the delete_while_booting, we can't soft delete, so it's always going to be a hard instance-is-gone
21:08:03 dansmith because we're just deleting the mapping
21:08:14 dansmith well, wait
21:08:55 dansmith yeah, right,
21:09:03 dansmith because if we deleted that, then we're going to end up with no instance record when the conductor realizes that we won
21:09:07 dansmith L1712
21:10:57 dansmith well, wait,
21:11:18 mriedem it seems like we just don't support soft_delete for the case that the instance isn't in a cell yet
21:11:19 dansmith yeah
21:11:28 dansmith right
21:11:38 mriedem soft_delete is also totally dependent on the compute deleting the instance
21:11:44 mriedem and if it never landed in a cell, there is no compute to clean it up
21:12:06 mriedem seems like a good comment to add in the code as a reminder of that
21:12:33 mriedem we could do that in a follow up, like my ask for a comment about why we avoid the lazy-load in the context manager for sys meta
21:12:45 mriedem cburgess: done, and the bp in lp too
21:13:28 cburgess cool
21:13:30 mriedem this patch still doesn't have a test to make sure that the soft_delete case is handled when the instance is in cell0
21:13:33 dansmith mriedem: yeah
21:13:55 dansmith mriedem: I can do that, or you can throw it in while you're stacking your others on top here
21:14:14 mriedem let me think about what i just said,
21:14:19 dansmith yeah, that...
21:14:22 dansmith would be a problem
21:14:27 mriedem if it's in cell0, again, it's we can't soft delete it
21:14:29 dansmith but there's also no resources to clean up
21:15:19 mriedem https://review.openstack.org/#/c/437222/7/nova/compute/api.py@2126
21:16:39 dansmith that cast is just going to go into the ether
21:16:59 dansmith if you delete it again, it hard deletes right?
21:18:03 openstackgerrit Sarafraj Singh proposed openstack/nova-specs master: WIP: Replace live migration steps and delays with memory iteration logic https://review.openstack.org/443339
21:20:25 dansmith mriedem: from the api perspective, what we have _might_ make the most sense
21:20:36 dansmith you soft delete, it stays around half deleted,
21:20:56 dansmith but never gets culled because there is no compute for it
21:20:57 dansmith then you hard delete it to make it go away
21:20:58 dansmith on the other hand,
21:21:09 mriedem you mean force-delete?
21:21:28 dansmith just making it kill the instance immediately if it's in cell0 also makes sense, since there's no reason to keep a dead instance around

Earlier   Later