Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-08
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
15:25:24 kashyap mriedem: I just checked the QEMU QAPI schema docs; the size there definitely means bytes.
15:25:49 kashyap Note, the 'size' you see there is the QEMU argument to the QMP command 'block_resize'
15:25:59 kashyap mriedem: What type of storage is this, BTW?
15:26:04 kashyap QCOW2?
15:27:39 lyarwood kashyap: are you sure that resize only takes Bytes?
15:27:54 mriedem kashyap: i'm not sure what the volume is that it's resizing to, but this is what it's resizing from (i think)
15:28:07 mriedem http://paste.openstack.org/show/601953/
15:28:24 kashyap lyarwood: If you see the pastebin from mriedem, on line-4, the quoted size is the argument to the QMP command 'block_resize'
15:28:40 kashyap mriedem: The QEMU folks are asking about the details of the kind of storage
15:29:18 mriedem this is where the size is calculated https://review.openstack.org/#/c/433793/3/nova/virt/libvirt/driver.py@1396
15:29:21 gibi tojuvone: thanks for the info. I still feel it would be nice to have a non nova impacting alternative mentioned in the spec. but I have no hard feelings is we go forward with the nova based solution
15:29:41 kashyap lyarwood: See line 996 there -- http://git.qemu-project.org/?p=qemu.git;a=blob;f=qapi/block-core.json;h=9bb7f4a17ba9765245616212542725c60ec361a1;hb=HEAD#l996
15:29:54 mriedem ibm a9000 is what they are resizing to
15:30:07 kashyap And, from what?
15:30:58 mriedem HP 3PAR
15:31:02 lyarwood kashyap: thanks

Earlier   Later