Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-08
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 johnthetubaguy mriedem: trust falls?
15:04:09 lbragstad mriedem you had some comments on one of johnthetubaguy's patches about using patrole (the RBAC testing project)
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 johnthetubaguy mriedem: nope
15:05:05 mriedem https://en.wikipedia.org/wiki/Trust_fall
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 tojuvone gibi, planned maintenance
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: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 mriedem kashyap: i found https://bugzilla.redhat.com/show_bug.cgi?id=1070531
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: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: Sort CellMappingList.get_all() for safety https://review.openstack.org/443174
15:22:52 openstackgerrit Dan Smith proposed openstack/nova master: Add functools.wraps to rapper https://review.openstack.org/443175
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.
15:24:06 mriedem the nova code says kb
15:24:07 mriedem dev.resize(resize_to * units.Gi / units.Ki)
15:24:42 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Final cleanups in conf/network https://review.openstack.org/431023
15:24:42 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Fix formatting of network options https://review.openstack.org/443086

Earlier   Later