| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-08 | |||
| 14:51:30 | cdent | gone | |
| 14:51:59 | jaypipes | mriedem: I've got three of those. | |
| 14:52:13 | mriedem | jaypipes: yeah but i assume they sleep and snore most of the night? | |
| 14:52:35 | cdent | until the apnea hits | |
| 14:52:37 | mriedem | lack of oxygen makes one tired | |
| 14:52:41 | jaypipes | mriedem: indeed. | |
| 14:52:54 | mriedem | the neighbor dog has a cocaine supply i'm pretty sure | |
| 14:53:53 | mriedem | dansmith: so net is, you're going to (1) sort cellmapping.get_all separately and (2) do a more efficient marker lookup separately for https://review.openstack.org/#/c/441388/ ? | |
| 14:54:14 | mriedem | the marker is the instance uuid, so we could find the cell that's in and page from there, but then we still potentially have other cells to iterate on after that one | |
| 14:54:22 | cdent | jaypipes: https://www.amazon.com/Crunchie-Milk-Chocolate-Honeycomb-Center/dp/B0007U5J40 that price isn't _that_ bad | |
| 14:55:21 | dansmith | mriedem: yeah.. it's going to make that mess a little more complicated, but seems reasonable | |
| 14:55:35 | gibi | tojuvone: I think it would worth to mention Craton integration as an alternattive | |
| 14:55:36 | mriedem | i left a note with that question | |
| 14:55:40 | jaypipes | cdent: heh, indeed. which reminds me, I owe you money :) | |
| 14:55:42 | mriedem | dansmith: since i don't have it worked out in my head | |
| 14:56:05 | mriedem | alex_xu: i'm +2 on https://review.openstack.org/#/c/441388/ now | |
| 14:56:49 | cdent | jaypipes: you do? if you're talking about for the ones I brought you, those are on the house | |
| 14:57:47 | mriedem | johnthetubaguy: i know you love policy questions, | |
| 14:57:52 | jaypipes | cdent: well, that's mighty fine of you, kind sir. | |
| 14:58:04 | cdent | first one's free! | |
| 14:58:30 | johnthetubaguy | mriedem: you called? | |
| 14:58:45 | mriedem | johnthetubaguy: for lock server, if i'm reading the code correctly, the owner of the instance that locks it is the user, not the project? so that users A and B in project X both have access to a server, but if user A locks the server, user B can't stop/restart it etc? | |
| 14:58:51 | mriedem | but can user B unlock it since they are in the same project? | |
| 14:59:05 | tojuvone | gibi: Craton holds information about any host in cloud, it should have the planned maintenance stuff, just that one should be aware of that somehow in Nova | |
| 14:59:32 | johnthetubaguy | mriedem: thats correct I believe, anyone in the project can do the unlcok | |
| 14:59:35 | johnthetubaguy | unlock | |
| 14:59:37 | tojuvone | gibi, And worked to have servers API to have always consistent state infromatino about host | |
| 14:59:49 | johnthetubaguy | mriedem: the user can't do any operations, unless they first unlock | |
| 15:00:01 | johnthetubaguy | mriedem: the admin can do any action without unlocking (I think...) | |
| 15:00:15 | johnthetubaguy | mriedem: also admin can apply the lock, so no users can remove it | |
| 15:00:22 | gibi | tojuvone: do you mean nova needs information about planned maintenance or you mean that the user looking at the nova REST API needs info about the maintenance? | |
| 15:00:42 | arne_r | Once again, calling attention to get https://review.openstack.org/#/c/436868/ in, after Lee gave it his blessing | |
| 15:00:52 | johnthetubaguy | mriedem: that service level spec of mine builds on top of all that, and adds a third layer in there | |
| 15:01:29 | tojuvone | gibi, user querying his servers from Nova should get consistent state information. Also know that maintenance is coming | |
| 15:01:40 | mriedem | johnthetubaguy: yeah that's all consistent with what i thought, | |
| 15:01:52 | mriedem | i just wanted to make sure that like if user A locks it that user B can still unlock it | |
| 15:02:03 | mriedem | which seems a bit wrong, | |
| 15:02:08 | johnthetubaguy | mriedem: ah, cool, I believe thats true | |
| 15:02:09 | mriedem | even though user B is an owner too because they are in the same project | |
| 15:02:22 | mriedem | at that point, user A just goes over and smacks user B | |
| 15:02:39 | johnthetubaguy | mriedem: our model assumes you trust (totally) everyone in your project | |
| 15:02:50 | mriedem | johnthetubaguy: trust falls?! | |
| 15:03:07 | johnthetubaguy | mriedem: we need hierarchical tenants to do better | |
| 15:04:05 | gibi | tojuvone: does a plannend maintenance part of a status of a server? on the same analogy does the status of a TOR switch part of the status of the server using that TOR switch? | |
| 15:04:09 | lbragstad | mriedem you had some comments on one of johnthetubaguy's patches about using patrole (the RBAC testing project) | |
| 15:04:09 | johnthetubaguy | mriedem: trust falls? | |
| 15:04:33 | johnthetubaguy | yeah, I prefer some in tree functional tests, regardless of what else is done | |
| 15:04:35 | lbragstad | mriedem turns out we will have some representation from that specific project in the policy meeting today to talk about it | |
| 15:04:50 | mriedem | johnthetubaguy: you don't know about trust falls? | |
| 15:05:05 | mriedem | https://en.wikipedia.org/wiki/Trust_fall | |
| 15:05:05 | johnthetubaguy | mriedem: nope | |
| 15:05:14 | johnthetubaguy | mriedem: oh... so I do | |
| 15:05:17 | lbragstad | mriedem so if you had any specific questions about patrole and are unable to make the meeting - i can proxy those for you | |
| 15:05:48 | johnthetubaguy | lbragstad: I should probably take a look at that | |
| 15:06:12 | mriedem | lbragstad: i don't | |
| 15:06:17 | lbragstad | mriedem ok | |
| 15:06:34 | tojuvone | gibi, Craton has also switches, so there is relation. | |
| 15:06:45 | lbragstad | mriedem if you do between now and 10 - just add them here https://etherpad.openstack.org/p/keystone-policy-meeting | |
| 15:07:18 | lbragstad | otherwise - i'll update that topic with a summary if what patrole is after the meeting (because i'm pretty sure that's the big question every has about it) | |
| 15:07:52 | gibi | tojuvone: would Craton push back the TOR switch status to nova to force a change on the status of the server using that TOR? | |
| 15:09:59 | tojuvone | gibi, So I say that you would have the relation known which hosts should go to maintenance if switch goes | |
| 15:10:37 | tojuvone | gibi, so you might put those into maintenance in Craton | |
| 15:10:56 | mriedem | lyarwood: kashyap: remember that block_resize failure thing I was talking about a week ago? got the libvirtd logs and they are super helpful (not really) :) http://paste.openstack.org/show/601952/ | |
| 15:10:56 | tojuvone | gibi, planned maintenance | |
| 15:11:06 | mriedem | "error": {"class": "GenericError", "desc": "Could not resize: Invalid argument"}} len=105 | |
| 15:11:23 | kashyap | mriedem: Hey, BTW, was reading scrollback this morning, heh, it's not Bulgaria | |
| 15:11:30 | kashyap | Ghent, Belgium :-) | |
| 15:12:01 | mriedem | ha | |
| 15:12:02 | dansmith | kashyap: damn | |
| 15:12:09 | mriedem | dansmith was infinitely closer | |
| 15:12:18 | mriedem | i got the B right | |
| 15:12:23 | dansmith | yeah, I win by the horseshoes and hand grenades rule | |
| 15:12:32 | tojuvone | gibi, And one should see that also trough Nova servers API | |
| 15:12:36 | kashyap | Yep; maybe he confused it because I was learning Dutch (and last night was my class, so left early) | |
| 15:12:58 | kashyap | mriedem: Okay, we've got at least the complete command libvirt is sending QEMU | |
| 15:13:07 | kashyap | From line-3, qemuMonitorJSONCommandWithFd:296 | |
| 15:13:10 | tojuvone | gibi, Surely also working the get alarm to user trough Vitrage | |
| 15:13:17 | kashyap | Now to decipher this error message, let me look a bit more | |
| 15:14:11 | gibi | tojuvone: I don't know. Today the I don't get network status or block device backend status through the GET /servers API but I can accept that planned maintenance is different and that might have place in the nova API | |
| 15:14:15 | tojuvone | gibi, as it could receive notification | |
| 15:14:26 | sfinucan | mriedem, johnthetubaguy: Could I ask you to take a look at the PCI weigher spec again? Think I've resolved all your comments https://review.openstack.org/#/c/364468/ | |
| 15:15:24 | gibi | tojuvone: I agree that we need to notify the end user I just wondering if this notification should come from nova our from carlton | |
| 15:15:44 | kashyap | mriedem: Yes, I remember the failure, let me check with QEMU folks on OFTC | |
| 15:16:38 | openstack | bugzilla.redhat.com bug 1070531 in qemu-kvm "qmp can not give a reasonable hint when block_resize a scsi_debug disk with 10G" [Low,Assigned] - Assigned to armbru | |
| 15:16:38 | mriedem | kashyap: i found https://bugzilla.redhat.com/show_bug.cgi?id=1070531 | |
| 15:16:45 | mriedem | i wonder if the size arg is too big? | |
| 15:16:55 | tojuvone | gibi, Craton would be building notifications soon. That is also something if not use Craton, then one might like to have the Nova notif | |
| 15:17:26 | kashyap | mriedem: Potentially; don't want to say something meaningless without digging a bit more :-) | |
| 15:17:54 | mriedem | if i'm looking at this correctly, it's a 15GB block resize | |
| 15:18:45 | gibi | tojuvone: does it mean there will be two alternative implementation of the same feature one in Nova and one in Craton? | |
| 15:18:49 | mriedem | umm, 15360GB? | |
| 15:19:00 | mriedem | self._guest._domain.blockResize(self._disk, size_kb) | |
| 15:19:14 | mriedem | "size":16106127360 | |
| 15:20:19 | kashyap | Oh dear | |
| 15:21:45 | tojuvone | gibi, For the notification? If you would use Craton, yes there would be 2 different then. | |
| 15:22:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Add functools.wraps to rapper https://review.openstack.org/443175 | |
| 15:22:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Sort CellMappingList.get_all() for safety https://review.openstack.org/443174 | |
| 15:23:03 | kashyap | mriedem: Isn't it 16GB? | |
| 15:23:20 | kashyap | It's the size in bytes | |
| 15:23:38 | kashyap | It is indeed 16GB. | |