| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-08 | |||
| 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: Resolve TODOs in 'database' https://review.openstack.org/393695 | |
| 12:07:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Fix indentation of database options https://review.openstack.org/443097 | |
| 12:12:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Short circuit notifiations when not enabled https://review.openstack.org/428260 | |
| 12:50:19 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Enable SR-IOV NIC offload feature discovery https://review.openstack.org/435954 | |
| 12:55:46 | alex_xu | nova api meeting is in 5 mins | |
| 12:58:08 | kaisers | Hi! Can i interested anyone to look into a smalish driver/systemd issue fix @ https://review.openstack.org/#/c/432344/ ? | |
| 13:21:17 | mriedem | o/ | |
| 13:21:47 | bhagyashri_s | johnthetubaguy: Hi, I have some doubt regarding patch: https://review.openstack.org/#/c/409644/ As we are decide to skip the image creation and delete the snapshot if rotation == 0. | |
| 13:22:08 | bhagyashri_s | johnthetubaguy: But As per the API spec: https://developer.openstack.org/api-ref/compute/, if the API is successful, it should return url of the image in the location header. But we are proposing not to create image when rotation parameter passed as 0 then in that case the location header will not exist so it seems like API behavior is changing in that case. | |
| 13:37:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Improve assertJsonEqual error reporting https://review.openstack.org/428199 | |
| 13:55:12 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add policy-docs spec https://review.openstack.org/433010 | |
| 14:01:04 | johnthetubaguy | bhagyashri_s: the current API never returns that header if rotation == 0 today, I believe | |
| 14:01:24 | alex_xu | johnthetubaguy: why need a method to get the scope, the scope depend on different instance? | |
| 14:01:41 | alex_xu | johnthetubaguy: ah, i see now | |
| 14:02:04 | alex_xu | still fill scope like {'project_id': instance.project} | |
| 14:02:11 | johnthetubaguy | alex_xu: yeah | |
| 14:02:38 | johnthetubaguy | alex_xu: maybe instance.get_scope() would do it, and keypair.get_scope() | |
| 14:02:49 | johnthetubaguy | alex_xu: its specific to the object passed, not the API | |
| 14:02:53 | alex_xu | johnthetubaguy: so you will have get_flavor_scope and get_global_scope | |
| 14:03:05 | alex_xu | yea, i see | |
| 14:03:33 | johnthetubaguy | alex_xu: well I think a constant for global scope, or something like that | |
| 14:20:11 | sean-k-mooney | hi everyone o/ | |
| 14:20:57 | sean-k-mooney | https://review.openstack.org/#/c/435575/ broke the intel NFV ci which is why it is currently red | |
| 14:27:29 | mriedem | sean-k-mooney: efried was talking about something similar | |
| 14:27:33 | mriedem | sounds like it broke powervm ci too | |
| 14:28:01 | mriedem | sean-k-mooney: how does it break the ci though? new package not in their mirror? | |
| 14:33:43 | gibi | cdent, mriedem: Hi! Sorry that I was not here to help digging the notification code to figure out the topic and the event_type prefix. (I work in UTC+1 so it was a bit late already) Is there anything from the notification side that stil needs clarification? | |
| 14:34:00 | mriedem | gibi: nope, you confirmed everything | |
| 14:34:09 | mriedem | plus i just chided you in the list about not working 20 hours per day :) | |
| 14:34:53 | gibi | yeah, I still try to keep a life outside work ;) | |
| 14:35:10 | cdent | there's an outside work? | |