| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-08 | |||
| 08:47:53 | alex_xu | Qiming: just think we should clear that it is admin-only in the default policy configration, it is configurable thing https://review.openstack.org/#/c/443000/1/api-ref/source/parameters.yaml | |
| 08:53:02 | openstackgerrit | huangtianhua proposed openstack/nova master: [DNM] Update quota usage when delete an instance without host https://review.openstack.org/443003 | |
| 08:56:21 | Qiming | really? | |
| 08:58:05 | Qiming | alex_xu, trying tox -e genpolicy | |
| 08:59:17 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova-specs master: Live Migration of Rescued Instances https://review.openstack.org/347161 | |
| 08:59:37 | alex_xu | Qiming: yes, but that single rule contorl multiple fields. you may want to expose "userdata" to the normal user, but you won't want to expose other fields like hypervisor_hostname to the normal user | |
| 09:00:12 | Qiming | alex_xu, wrt those two I agree | |
| 09:00:21 | Qiming | alex_xu, how about others? | |
| 09:01:11 | Qiming | alex_xu, filed a bug on this, https://bugs.launchpad.net/nova/+bug/1670978 | |
| 09:01:11 | openstack | Launchpad bug 1670978 in OpenStack Compute (nova) "most of extended server attributes returned in 2.3 api versions should not require admin role" [Undecided,New] | |
| 09:01:42 | alex_xu | Qiming: ah, wait, that hostname is the instance's hostname | |
| 09:02:08 | alex_xu | Qiming: I feel we can expose all of them to the normal user. | |
| 09:04:06 | Qiming | alex_xu, glad to know that | |
| 09:37:21 | openstackgerrit | Li Yingjun proposed openstack/nova master: Error message should not include SQL command https://review.openstack.org/436773 | |
| 09:39:12 | johnthetubaguy | alex_xu: I thought hostname was the hypervisor hostname, is that a different one? | |
| 09:39:39 | alex_xu | johnthetubaguy: that is the different one, it comes from objects.Instance.hostname | |
| 09:40:02 | johnthetubaguy | oh, OK | |
| 09:40:18 | johnthetubaguy | thats the possibly truncated name I guess | |
| 09:41:11 | alex_xu | johnthetubaguy: yea, https://github.com/openstack/nova/blob/master/nova/compute/api.py#L590 | |
| 09:41:44 | alex_xu | johnthetubaguy: so we can change some admin fields to non-admin fields without microversion, right? | |
| 09:41:48 | johnthetubaguy | yeah, seems like the policy default is wrong then | |
| 09:41:57 | johnthetubaguy | alex_xu: yeah, just a release note about the upgrade impact | |
| 09:42:48 | alex_xu | johnthetubaguy: yes, capabilities API, remove all my confuse | |
| 09:42:51 | alex_xu | :) | |
| 09:42:56 | johnthetubaguy | :) | |
| 09:43:06 | alex_xu | johnthetubaguy: few thinking https://review.openstack.org/#/c/433037/12/specs/pike/approved/policy-remove-scope-checks.rst | |
| 09:44:33 | johnthetubaguy | alex_xu: yeah, scope is a tricky one, if we do hierarchy too | |
| 09:45:16 | johnthetubaguy | alex_xu: probably "global visibility = TRUE/FALSE" might be worth adding in the extended list | |
| 09:45:32 | alex_xu | johnthetubaguy: do you have example what scope will looks like with hierarchy? i can't image that, maybe I should think about more hierarchy first | |
| 09:45:51 | johnthetubaguy | so project A is parent of B and C | |
| 09:46:01 | johnthetubaguy | you login as global read of project A | |
| 09:46:16 | johnthetubaguy | maybe you should be able to also read servers in B and C | |
| 09:46:29 | johnthetubaguy | maybe all_tenants=True gives you a list of all servers across A, B and C | |
| 09:46:37 | johnthetubaguy | alex_xu: does that make any sense? | |
| 09:47:10 | alex_xu | johnthetubaguy: yea, that make sense | |
| 09:47:11 | johnthetubaguy | oops, I said global read of project A | |
| 09:47:18 | johnthetubaguy | I meant read in project A | |
| 09:47:36 | alex_xu | i think i got that | |
| 09:47:49 | johnthetubaguy | now I am not 100% if we want to do that, but good to leave the door open to that | |
| 09:47:53 | alex_xu | try to think about how to match that into scope check | |
| 09:48:04 | johnthetubaguy | think of a server GET | |
| 09:48:13 | johnthetubaguy | you have a token for project A | |
| 09:48:20 | johnthetubaguy | but you GET an instance in project B | |
| 09:48:47 | johnthetubaguy | because A is parent of B, we could make the scope check pass, even though token.project_id != server.project_id and token is not global scoped | |
| 09:49:45 | alex_xu | at that time, we should depend on context.project_id anymore I guess | |
| 09:49:57 | alex_xu | s/should/shouldn't/ | |
| 09:50:50 | bauzas | alex_xu: objects.Instance.hostname ? OMG, what's this ? | |
| 09:51:06 | alex_xu | bauzas: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L590, the hostname of guest | |
| 09:51:09 | johnthetubaguy | alex_xu: right, the scope check checks the hierarchy and the project | |
| 09:51:32 | bauzas | alex_xu: ah the instance name, gotcha | |
| 09:51:45 | bauzas | oh wait, no | |
| 09:52:29 | bauzas | yeah, not the display name, some weird thing | |
| 09:54:22 | alex_xu | johnthetubaguy: ok, i guess scope parameter still be the {"project_id": project_id}, then context object have attribute about hierarchy projects. Then check_scope proably can do the hierarchy check | |
| 09:54:34 | alex_xu | bauzas: yea | |
| 09:55:10 | alex_xu | johnthetubaguy: bauzas have to leave now. back later | |
| 09:55:30 | johnthetubaguy | alex_xu: yeah, thats totally it | |
| 09:55:36 | johnthetubaguy | alex_xu: catch you later | |
| 09:55:58 | johnthetubaguy | bauzas: think windows VMs with hostname limits, and user passing in very long names | |
| 09:56:17 | bauzas | I see | |
| 10:11:17 | openstackgerrit | Qiming Teng proposed openstack/nova master: Fix API doc about server attributes (2.3 API) https://review.openstack.org/443000 | |
| 10:28:27 | mdbooth | johnthetubaguy: More swap_volume fun, btw: https://review.openstack.org/#/c/389798/ | |
| 10:28:52 | mdbooth | johnthetubaguy: In that change, the issue we have is that cinder is deferring the copy operation to Nova, but Nova isn't always able to do it | |
| 10:29:17 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Optimize time during PCI alias parsing process https://review.openstack.org/427145 | |
| 10:29:33 | johnthetubaguy | mdbooth: yeah, isn't that the general problem with swap volume? I think thats why I couldn't use that in public cloud | |
| 10:29:47 | johnthetubaguy | neither side had the ability to do a "live" clone or copy | |
| 10:29:54 | mdbooth | kashyap: I also added you to https://review.openstack.org/#/c/389798/ btw, because I'm wondering about what the behaviour of rebase is in various domain states. | |
| 10:30:09 | lyarwood | mdbooth: I've got a RHBZ downstream to enable offline swap_volume btw | |
| 10:30:38 | johnthetubaguy | lyarwood: "offline"? you mean pause the VM? | |
| 10:30:41 | kashyap | mdbooth: BTW, in the scrollback there was an interesting question. Was gathering the related IRC chatter: | |
| 10:30:46 | mdbooth | johnthetubaguy: I think you can do it, you'd just need to ensure Nova doesn't bring the instance up while cinder is doing the copy | |
| 10:31:05 | johnthetubaguy | mdbooth: but the instance is running during swap volume, I thought? | |
| 10:31:08 | kashyap | mdbooth: When you have a moment: http://paste.openstack.org/show/601900/ | |
| 10:31:15 | lyarwood | johnthetubaguy: yeah paused, shutoff, any state where qemu can't rebase | |
| 10:31:25 | mdbooth | johnthetubaguy: Yes, unless it's not. | |
| 10:31:35 | johnthetubaguy | mdbooth: lyarwood: OK, gotcha | |
| 10:31:36 | mdbooth | If it's not, we currently fail. | |
| 10:31:39 | johnthetubaguy | like live-migration really | |
| 10:31:57 | johnthetubaguy | (although that actually has some error handling) | |
| 10:32:29 | mdbooth | johnthetubaguy: Anyway, I was asking for a rethink of swap_volume in that cinderv3 spec, and this seemed relevant to that. | |
| 10:32:44 | johnthetubaguy | mdbooth: yeah, I need to read through your comments on there | |
| 10:32:46 | mdbooth | Although it's not directly related to attach/detach. | |
| 10:33:02 | johnthetubaguy | mdbooth: it feels like we have both volumes attached for some time, then tidy it up afterwards right? | |
| 10:33:22 | johnthetubaguy | attached, is the wrong word, I mean connected | |
| 10:33:33 | mdbooth | There's a really weird flow if cinder initiates the swap_volume | |
| 10:33:55 | johnthetubaguy | OK, I should read that more carefully then | |
| 10:34:15 | mdbooth | During a cinder retype, cinder creates a *new, blank volume*, and calls swap_volume(old, new_blank) | |
| 10:34:23 | mdbooth | new_blank obviously has its own volume_id | |
| 10:34:38 | mdbooth | Nova then does the copy, and calls back with completion | |
| 10:34:57 | mdbooth | Cinder then deletes old, and changes the volume_id of new_blank to be the same as old | |
| 10:35:12 | mdbooth | Which means that for part of the flow we've got an ephemeral volume_id | |
| 10:35:39 | mdbooth | And Nova currently needs to know that the volume_id of new_blank after the callback isn't the same as it was before. | |
| 10:35:50 | kashyap | mdbooth: That's an interesting question (rebase behavior in different domain states) you ask there on the review. I'll dig a bit & and comment on the review. | |
| 10:35:58 | mdbooth | johnthetubaguy: It's really quite horrible. | |
| 10:36:20 | kashyap | s/interesting/not-easily-answerable/ | |
| 10:36:26 | mdbooth | kashyap: Thanks | |
| 10:36:33 | johnthetubaguy | mdbooth: oh, I forgot about that rename again, yeah, I remember looking at that now | |
| 10:37:30 | mdbooth | johnthetubaguy: Anyway, that's why I was going on about attachment id instead. | |
| 10:37:52 | mdbooth | My theory is cinder can do unnatural things on the back end and Nova doesn't need to care as long as the attachment id doesn't change. | |
| 10:38:38 | johnthetubaguy | mdbooth: hmm, but don't we need to call os.brick.connect and disconnect during the swap? | |
| 10:39:02 | mdbooth | johnthetubaguy: yes, but the 2 attachments have different connection_info | |