| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-21 | |||
| 21:16:29 | mriedem | "In addition we should only use the new API when all of the nova-compute nodes have been upgraded." | |
| 21:17:05 | mriedem | so if we only create a new attachment when cinder 3.27 is available and all computes are upgraded, then during swap_volume we can create the new attachment for the new volume based on bdm.attachment_id being set for the old volume | |
| 21:17:31 | mriedem | we could pass the new attachment_id over rpc to swap_volume on the compute | |
| 21:18:32 | coffee_cat | mriedem: we don't call reserve with the new flow | |
| 21:18:53 | mriedem | coffee_cat: yeah ok so then we need to create the new attachment in the api | |
| 21:18:58 | coffee_cat | mriedem: attachment_create without connector acts as reserve in the sense of putting the volume in 'reserved' state | |
| 21:19:05 | mriedem | and pass the attachment id down to the compute over rpc, or the compute can look it up | |
| 21:19:52 | coffee_cat | I guess passing it to the compute should be fine if we don't want to call out to Cinder that much | |
| 21:20:47 | mriedem | the compute could lookup the attachments for the new volume... | |
| 21:21:02 | mriedem | since the cinder api isn't documented, i don't know what it looks like | |
| 21:21:38 | coffee_cat | mriedem: also we need to figure out on the compute too how to finalize the attachment process | |
| 21:21:58 | coffee_cat | we might do that by using receiving an attachment_id from the API as a trigger | |
| 21:22:38 | coffee_cat | or list the attachments with the call from the new flow too I guess | |
| 21:23:22 | mriedem | we update the attachment with the connector | |
| 21:24:38 | coffee_cat | I meant that we need to know on the compute that the API reserved the volume with the new flow | |
| 21:24:50 | coffee_cat | and we need to call attachment_update at some point | |
| 21:25:05 | coffee_cat | with the connector | |
| 21:25:34 | mriedem | if bdm.attachment_id is set, we know the api reserved the new volume with the new flow | |
| 21:25:47 | mriedem | so i think https://review.openstack.org/#/c/456971/ gets more complicated than just updating the compute code | |
| 21:25:50 | mriedem | it should also be the api code | |
| 21:25:54 | mriedem | and the rpc api changes | |
| 21:26:09 | mriedem | unless we just want to lookup the new attachment via rest api | |
| 21:26:17 | mriedem | i just don't know if we have that support yet in cinderclient | |
| 21:26:53 | mriedem | i could help work on this if you want | |
| 21:27:02 | mriedem | i just can't do it today | |
| 21:28:02 | mriedem | it would be great if you guys could get the v3.27 APIs documented in https://developer.openstack.org/api-ref/block-storage/v3/ | |
| 21:28:04 | mriedem | you == all of cinder | |
| 21:28:31 | mriedem | and by "guys" i mean guys and gals and those that don't identify as guys or gals, of course | |
| 21:31:12 | coffee_cat | mriedem: got it :) | |
| 21:31:32 | mriedem | it looks like from the compute we could list attachments and filter on instance_uuid | |
| 21:31:53 | coffee_cat | and yeah, if the bdm.attachment_id is set then all computes should be on the high enough version, etc. | |
| 21:32:23 | coffee_cat | we should definitely be able to do that if we want to skip the rpc changes, which I'm totally fine with | |
| 21:32:28 | mriedem | we could get attachments via cinderclient for a given volume and instance | |
| 21:32:33 | mriedem | using filters it looks like | |
| 21:32:40 | jgriffith | mriedem correct | |
| 21:33:01 | mriedem | if we got more than one attachment back...idk | |
| 21:33:10 | mriedem | we shouldn't today since we don't support multiattach | |
| 21:33:12 | mriedem | but it gets weird | |
| 21:33:21 | mriedem | that's probably why it's just better to pass the new attachment id over rpc | |
| 21:33:22 | jgriffith | mriedem right, for today that’s our safety net | |
| 21:33:22 | mriedem | to the compute | |
| 21:33:26 | mriedem | rather than hae the compute guess | |
| 21:33:30 | jgriffith | BUT, there’s a get-attachment | |
| 21:33:35 | coffee_cat | mriedem: although for live migrate etc we should be able to have multiple attachments for the same volume | |
| 21:33:51 | coffee_cat | which should not make a mess for swap volume, but still | |
| 21:33:58 | mriedem | i think passing over rpc is safest | |
| 21:34:05 | mriedem | then compute doesn't need to decide | |
| 21:34:23 | mriedem | again, i can help with this later, but i'm getting in trouble for hiding in the office when it's a nice day out | |
| 21:34:24 | coffee_cat | agreed | |
| 21:34:38 | mriedem | so i'm forcefully detaching from this computer, ttyl | |
| 21:34:54 | coffee_cat | mriedem: have a good weekend :) | |
| 22:14:18 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: nova.utils.get_service_url(group) https://review.openstack.org/458257 | |
| 22:15:11 | efried | mriedem johnthetubaguy mordred If possible I'd like y'all to start looking at ^^ - let me know if the approach is remotely sane, and maybe answer some of the open questions in the comments. | |
| 22:15:50 | efried | Wait, was it johnthetubaguy or jaypipes? Well, jaypipes isn't here, so... | |
| 22:17:50 | mordred | it was jay - I have it open in my browser - I'm heads down on a different patch at the moment, but I'll come back and give you some feedback RSN | |
| 22:18:05 | mordred | leakypipes: ^^ | |
| 22:22:22 | efried | mordred Thanks. No hurry, think I'm gonna bounce for the night. | |
| 23:16:39 | leakypipes | mriedem: oh, you didn't appreciate my playground rock-paper-scissors humour? boo. | |
| #openstack-nova - 2017-04-22 | |||
| 01:11:27 | chatter29 | hey guys | |
| 01:11:29 | chatter29 | allah is doing | |
| 01:11:34 | chatter29 | sun is not doing allah is doing | |
| 01:11:36 | chatter29 | to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger | |
| #openstack-nova - 2017-04-23 | |||
| 08:50:15 | openstackgerrit | Abhishek Sharma M proposed openstack/nova master: Catching OverLimit Exception https://review.openstack.org/455118 | |
| 13:30:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add Cinder v3 detach call to _terminate_volume_connections https://review.openstack.org/456896 | |
| 13:30:55 | mriedem | ildikov: addressed comments ^ i'm going to add a new patch on top of this that adds attachment_create, and then redo the swap_volume patch on top of that | |
| 13:32:46 | mriedem | and attachment_update i guess | |
| 13:37:21 | mriedem | jgriffith: is there a quota limit on volume attachments? | |
| 13:38:33 | mriedem | doesn't look like it | |
| 13:44:30 | ildikov | mriedem: isn't it still Sunday? I have a longer route to home than I expected so I cannot follow what day it is anymore... :) | |
| 13:44:43 | mriedem | yeah it's sunday morning | |
| 13:44:57 | mriedem | i think there also might be a bug in the cinder v3 attachment create api | |
| 13:45:04 | mriedem | or the attachments view builder rather | |
| 13:45:11 | mriedem | oh wait nvm | |
| 13:45:27 | ildikov | mriedem: i haven't seen any quota limits for attachments | |
| 13:45:45 | ildikov | mriedem: there was so | |
| 13:46:34 | ildikov | *some bug fixing activity with that already | |
| 13:46:46 | mriedem | i was just reading the view builder code incorrectly | |
| 13:46:47 | mriedem | it's ok | |
| 13:51:59 | ildikov | ok, cool | |
| 13:52:46 | ildikov | sorry, I couldn't get to that chain earlier | |
| 13:52:52 | ildikov | thanks for looking into it! | |
| 13:53:00 | mriedem | np | |
| 13:53:54 | ildikov | I will try to entertain myself with the two standalone patches on the plane today and get tests up | |
| 14:10:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: cinder: add attachment_create method https://review.openstack.org/459111 | |
| 14:53:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: cinder: add attachment_create method https://review.openstack.org/459111 | |
| 15:10:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: cinder: add attachment_update method https://review.openstack.org/459113 | |
| 15:43:27 | mriedem | mordred: i'm trying to fill out the project version navigator for nova, and going back to austin, it looks like the openstack route didn't actually return versions :) | |
| 15:43:30 | mriedem | the ec2 route did | |
| 15:43:41 | mriedem | https://github.com/openstack/nova/blob/c364724a0dc7a658058fcb167af66ee7eb5bcd2a/nova/api/openstack/__init__.py | |
| 15:44:10 | mriedem | https://github.com/openstack/nova/blob/c364724a0dc7a658058fcb167af66ee7eb5bcd2a/nova/api/ec2/__init__.py#L266 | |
| 15:44:16 | mriedem | that 1.0 in the ec2 route versions must have been for openstak | |
| 15:44:19 | mriedem | *openstack | |
| 15:56:16 | mriedem | or i guess it was 1.0 for ec2? | |
| 16:08:05 | mriedem | ooo snap i found the 2010.1 code on launchpad | |
| 20:48:39 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/458834 | |
| 22:31:34 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Update cinder-new-attach-apis spec for begin_detaching https://review.openstack.org/459134 | |
| #openstack-nova - 2017-04-24 | |||
| 00:51:08 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (2/4) https://review.openstack.org/455568 | |
| 00:51:59 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (3/4) https://review.openstack.org/455570 | |
| 00:52:10 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers-actions (4/4) https://review.openstack.org/455573 | |
| 00:52:31 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Example verification for servers-actions.inc https://review.openstack.org/454565 | |