| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-20 | |||
| 13:31:22 | efried | But we would have to enable/support it. | |
| 13:31:34 | mriedem | jaypipes or cdent or edleafe can correct me if i'm wrong | |
| 13:32:17 | edleafe | mriedem: correctamundo | |
| 13:33:41 | jaypipes | efried: totes. the VIOSes in AIX on PVM SSPs on SAN. yep, totes. | |
| 13:34:01 | openstackgerrit | Sandeep Pawar proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951 | |
| 13:36:09 | thorst | efried: yeah, we should definitely fold into that concept... (was afk) | |
| 13:36:50 | efried | thorst adreznec Let's queue it up for discussion in our box doc. | |
| 13:37:38 | thorst | yep | |
| 13:37:49 | thorst | we may have some FS ones in the same boat. | |
| 13:39:12 | efried | thorst Though it looks like maybe there is no affordance for it to be automated - the deployer just has to know which hosts are sharing an SSP and run these resource-provider set inventory commands accordingly. | |
| 13:40:00 | thorst | well, we've got a command to tell them all the hosts sharing...so. Maybe something to doc for that process. | |
| 13:40:38 | efried | Would be kinda neat if there was a method on the compute driver that could be asked to provide some kind of identifier for the shared resource (the SSP UUID in this case?) so the controller can figure out the pool on its own. | |
| 13:40:50 | efried | mriedem edleafe jaypipes Future enhancement ^^ ? | |
| 13:41:24 | efried | (though I haven't finished reading the spec yet ;-) | |
| 13:41:37 | jaypipes | efried: in case it wasn't obvious, I was being sarcastic above. :) | |
| 13:42:07 | efried | jaypipes Oh, it wasn't. | |
| 13:42:10 | efried | To me | |
| 13:42:22 | jaypipes | efried: I was poking fun at your TLAs :P | |
| 13:42:41 | efried | Gotcha. IBM does love its TLAs. | |
| 13:42:59 | jaypipes | efried: joking aside, I don't see anything that would prevent SSPs from being used as shared resource providers, no. | |
| 13:43:28 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for resource providers https://review.openstack.org/457532 | |
| 13:43:29 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for inventories https://review.openstack.org/457533 | |
| 13:43:29 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for allocations https://review.openstack.org/457534 | |
| 13:43:29 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for usages https://review.openstack.org/457535 | |
| 13:43:44 | efried | jaypipes Agree. But seems like it should be possible without operator intervention - at least in the narrow case I'm thinking about. | |
| 13:44:15 | jaypipes | efried: yes, indeed. | |
| 13:44:21 | efried | Not sure if possible in the general case. | |
| 13:44:47 | efried | I would think it should be possible if the shared storage was via NFS. | |
| 13:45:10 | efried | As long as the computes had a reliable way to canonicalize the host and mountpoint. | |
| 13:45:17 | rpodolyaka | cdent: thanks for your input on osc-placement changes! it's good to have a pair of fresh eyes on this | |
| 13:46:08 | thorst | could do the old - have each compute create a file on the share...and then have the compute drivers report back what they see. From that you could figure out who can see who... | |
| 13:46:15 | openstackgerrit | Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597 | |
| 13:47:37 | cdent | rpodolyaka: you're very welcome | |
| 13:48:05 | lyarwood | mriedem: would you be willing to approve the bp for ^ https://blueprints.launchpad.net/nova/+spec/switch-to-os-brick-encryptor-classes or should I bring it up during the meeting today? | |
| 13:51:17 | mriedem | lyarwood: bring it up during open discussion | |
| 13:51:24 | lyarwood | mriedem: ack thanks | |
| 13:53:04 | cdent | johnthetubaguy: I've seen your comments on the service stuff on https://review.openstack.org/#/c/457283/ and I'm confused on one point that you might be able to help me on: | |
| 13:53:37 | cdent | johnthetubaguy: do we expect the host field in the service record to be the same or different for each instance of the wsgi app? | |
| 13:54:20 | johnthetubaguy | cdent: I think we want an entry for each version that is installed | |
| 13:54:29 | johnthetubaguy | cdent: so we can tell when the upgrade has finished | |
| 13:54:38 | johnthetubaguy | (or not) | |
| 13:54:51 | cdent | that doesn't really answer my question :) | |
| 13:55:15 | johnthetubaguy | cdent: true, I think the answer is yes, but the above is why | |
| 13:55:41 | johnthetubaguy | oops, by yes, I mean different for each instance | |
| 13:55:59 | johnthetubaguy | the problem is cleaning up old ones, etc, its a bit... unexpected | |
| 13:56:14 | cdent | so many knobs | |
| 13:56:31 | cdent | okay, I'll make some adjustments. using CONF.host seems like a reasonable way to go | |
| 13:56:56 | johnthetubaguy | cdent: I think this is the extra context: https://review.openstack.org/#/c/384724/ and https://launchpad.net/bugs/1631430 | |
| 13:56:56 | openstack | Launchpad bug 1631430 in OpenStack Compute (nova) "Only one entry created for nova-osapi_compute and nova-metadata services in multi-n-api environment" [Medium,In progress] - Assigned to Sujitha (sujitha-neti) | |
| 13:57:11 | mriedem | nova meeting in 3 minutes in #openstack-meeting | |
| 13:57:33 | cdent | thanks johnthetubaguy | |
| 13:58:41 | openstackgerrit | sahid proposed openstack/nova master: network: add command to configure trusted mode for VFs https://review.openstack.org/458513 | |
| 13:58:42 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 13:58:53 | mdbooth | sfinucan johnthetubaguy mriedem: I'd really like to push this one over the line: https://review.openstack.org/#/c/383859/ . Appreciate it's a pretty complex, though. I was thinking about splitting out the code which resets on libvirt reconnection into a separate patch. I still think this code adds robustness, but splitting it out might make it simpler to review the most important part of the patch. Worth it? | |
| 13:59:26 | mriedem | i wouldn't split it | |
| 13:59:31 | sfinucan | I wouldn't | |
| 13:59:41 | mdbooth | Glad I asked :) | |
| 14:00:09 | sfinucan | Yeah, I'm generally happy with it as is. The tests are by far the most complex piece but copious comments do help | |
| 14:00:34 | johnthetubaguy | yeah, I think I am quite close to +2 on that now, its dropped off my radar for a bit | |
| 14:00:43 | mdbooth | Yeah, the tests are a nightmare | |
| 14:00:43 | johnthetubaguy | will try taking another peak today | |
| 14:01:04 | mdbooth | Ok, thanks. I'll update with sfinucan's comments, but otherwise leave it alone. | |
| 14:02:25 | sfinucan | (y) | |
| 14:21:30 | traskat | hey, what i have to do to apply extra specs to running VMs for examaple disk IO limitations without restart the VM? | |
| 14:25:13 | efried | traskat Resize? | |
| 14:25:31 | efried | (I don't know the answer, just an idea.) | |
| 14:29:05 | traskat | efried, you mean to another flavor ? | |
| 14:29:32 | efried | traskat I would think so. Where else would you get the new extra_specs? | |
| 14:30:09 | efried | traskat Prolly depends on the driver whether the resize can happen without a reboot... | |
| 14:30:42 | efried | But then, the extra_specs will be driver-specific anyway, não é? | |
| 14:39:26 | openstackgerrit | Mathieu Gagné proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 14:40:40 | imacdonn | mdbooth, around ? | |
| 14:40:50 | mdbooth | imacdonn: Yep | |
| 14:41:01 | mriedem | takashin: alex_xu: ok did you want to talk about the server migrations API? | |
| 14:41:06 | imacdonn | hi! Could you take a peek at https://bugs.launchpad.net/nova/+bug/1683972 ? | |
| 14:41:06 | openstack | Launchpad bug 1662483 in OpenStack Compute (nova) "duplicate for #1683972 detach_volume races with delete" [Undecided,In progress] - Assigned to Matthew Booth (mbooth-9) | |
| 14:41:06 | mriedem | or wait for me to write something up? | |
| 14:41:08 | alex_xu | mriedem: yea | |
| 14:41:23 | takashin | mriedem: yes. | |
| 14:41:25 | alex_xu | I just didn't remember why we only show in-progress initially | |
| 14:41:46 | mriedem | alex_xu: because the api was written solely to cancel in-progress live migratoins | |
| 14:41:48 | mriedem | *migrations | |
| 14:41:53 | mdbooth | imacdonn: Looking | |
| 14:41:58 | imacdonn | mdbooth, thanks | |
| 14:42:04 | takashin | alex_xu: There is os-migrations API. | |
| 14:42:26 | takashin | alex_xu: We can use it to list all migrations. | |
| 14:42:29 | mriedem | alex_xu: so rather than just having to validate when a request is made to cancel a live migration, we filtered out the migrations you could pick from to do the cancel | |
| 14:43:25 | takashin | mriedem: Yes. To cancel a live migration. | |
| 14:44:06 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrations.py#L62 | |
| 14:44:21 | mriedem | so before 2.23, we can list all migrations, but we don't expose the type | |
| 14:44:26 | mdbooth | imacdonn: Fun | |
| 14:44:28 | mriedem | because add_link defaults to False | |
| 14:44:35 | alex_xu | mriedem: that works for me. I guess initialy we think there is only one migration, and we didn't want to trouble with user to find out which migration is in-progress. | |
| 14:44:37 | imacdonn | mdbooth :) indeed | |
| 14:45:17 | alex_xu | with filter, we can reach the same goal | |
| 14:45:21 | mriedem | at microversion >= 2.23 with os-migrations, we provide a link and migration_type in the response for an in-progress live migration, otherwise just the migration_type | |
| 14:45:35 | mriedem | alex_xu: note that os-migrations also takes a filter parameter | |
| 14:45:40 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrations.py#L77 | |
| 14:45:47 | alex_xu | so i'm ok with that. and the user have one more way to query all the migraitons for a specific servers, so nothing bad at here | |
| 14:45:50 | mriedem | it's not validated, but it's there | |