Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-08
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
10:39:07 mdbooth Because they're in different places
10:39:25 johnthetubaguy yeah, totally, I worry if thats the same attachment_id
10:39:39 johnthetubaguy I like a different attachment_id for the different targets
10:40:27 mdbooth We'd have 2 attachments: (vol, host, instance), and (vol', host, instance)
10:40:31 johnthetubaguy just nice to say, create new attachment, then connect, kill old attachment after disconnect
10:40:37 johnthetubaguy yeah
10:40:43 mdbooth Although vol and vol' are kinda the same volume, which might get a bit wierd
10:40:50 mdbooth But we don't need to care
10:40:55 johnthetubaguy oh, sorry, I think I get you now
10:41:07 johnthetubaguy we are maybe trying to say the same thing
10:41:34 johnthetubaguy so when cinder renames the volume uuid to something nuts, we don't notice because the attachment_id stays the same?
10:41:47 mdbooth Yeah
10:41:53 johnthetubaguy yeah, I am totally +1 that
10:41:59 mdbooth But the connect/disconnect flow remains basically the same
10:42:04 johnthetubaguy yeah
10:42:20 kashyap inc0: Hey there, saw the scrollback between you & MattR about libvirt 2.5 & running `nova-compute` process with a different user than QEMU causing you permission woes
10:42:35 johnthetubaguy mdbooth: I think thats what I was trying to say, but I guess it didn't come out like that
10:43:24 johnthetubaguy mdbooth: actually, what I mean is, its an assumption I had made but not really written down
10:43:26 kashyap inc0: I also see that your permissions problem 'goes away' when you run QEMU with 'nova' user.
10:43:48 kashyap It would be useful if you have a bug / specific test case.
11:01:52 mdbooth I'd like to nominate dansmith for best patch title: "Target cell in super conductor operations"
11:02:27 mdbooth Expect a movie by Michael Bay
11:09:35 kashyap Heh
11:23:36 tonyb lyarwood: I've been avoiding that s390x backport ... thanks for calling me out on it ;P
11:25:17 tonyb lyarwood: just 'cause it's complex
11:30:33 lyarwood tonyb: you're welcome :D
11:30:40 tonyb :)
11:30:57 lyarwood tonyb: do we have any policy about stable only changes like this?
11:32:40 tonyb lyarwood: only the stable-policy which basically says if it isn't a backport then it isn't appropriate
11:33:14 tonyb but the tricks in the fine print. If we can convince ourselves it's as close to a backport as we can reasonably do then we can look at it
11:33:45 tonyb lyarwood: but we need to consider what our support for s390x is ....
11:34:05 tonyb lyarwood: I'm not certain it's a thing we have a firm statement on :(
11:34:33 lyarwood tonyb: yeah agreed
11:36:12 tonyb lyarwood: I wish I could be more definative
11:37:10 lyarwood tonyb: https://docs.openstack.org/developer/nova/support-matrix.html does list s390x as `complete`
11:37:18 lyarwood ah sorry
11:37:22 lyarwood that's per feature
11:37:28 tonyb lyarwood: Yeah
11:41:31 openstackgerrit Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597
11:43:27 openstackgerrit Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597
12:01:32 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Fix formatting of network options https://review.openstack.org/443086
12:05:57 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - servers.py https://review.openstack.org/359861
12:06:05 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - manager.py https://review.openstack.org/359868
12:06:11 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - linux_net.py https://review.openstack.org/359871
12:06:18 openstackgerrit Alex Szarka proposed openstack/nova master: Reduce code complexity - libvirt/config.py https://review.openstack.org/359879
12:07:50 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Fix indentation of database options https://review.openstack.org/443097
12:07:50 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Resolve TODOs in 'database' https://review.openstack.org/393695
12:12:15 openstackgerrit Balazs Gibizer proposed openstack/nova master: Short circuit notifiations when not enabled https://review.openstack.org/428260

Earlier   Later